IdentifiantMot de passe
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Quelles sont les erreurs les plus commises par de nouveaux développeurs ?
Et comment les éviter ?

Le , par Katleen Erna
116 commentaires

10PARTAGES

1  0 
Quelles sont les erreurs les plus communément commises par de nouveaux programmeurs ?
Incapacité d'estimer le temps nécessaire à l'accomplissement d'une tâche
60 %
Ne pas demander d'aide
41 %
Passivité en cas de problème récurrent
25 %
Ne pas suivre les standards de l'équipe
25 %
Dévier de l'architecture prévue sans prévenir
23 %
Écrire du code trop compliqué pour crâner
18 %
Autre (merci de préciser)
8 %
Voter 169 votants
Quelles sont les erreurs les plus communément commises par de nouveaux programmeurs ? Et comment les éviter ?

La situation est assez fréquente. Une entreprise, un service informatique...et un petit nouveau qui arrive. Le jeune développeur a évidemment beaucoup moins d'expérience que ses aînés, ce qui peut l'amener à commettre certaines erreurs. Parfois, les "anciens" remarquent que les "nouveaux" font toujours le même type d'erreurs. Aussi, il serait bon de connaître les manquements les plus fréquents, afin de pouvoir les éviter.

Alors, selon vous et votre expérience, quelle est l'erreur la plus communément commise par une toute fraîche recrue ?

Voici déjà une liste de suggestions. Libre à vous d'en rajouter d'autres :

- Ne pas demander d'aide. Souvent, par manque de courage ou au contraire par excès de confiance en soit.

- Passivité en cas de problème récurrent.

- Incapacité d'estimer le temps nécessaire à l'accomplissement d'une tâche. Variante : promettre de terminer un travail en deux semaines, lorsque l'on sait pertinemment qu'il en demandera trois.

- Ne pas suivre les standards de l'équipe.

- Écrire du code trop compliqué pour crâner

- Dévier de l'architecture prévue sans prévenir

Avez-vous souvent été confrontés à ce type de comportements ? En avez-vous relevé d'autres ?

Comment éviter ces erreurs ?
Vous avez lu gratuitement 22 articles depuis plus d'un an.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer à vous proposer des publications.

Une erreur dans cette actualité ? Signalez-nous-la !

116 commentaires
Commenter Signaler un problème
Le_Phasme
Avatar de Le_Phasme
Membre régulier https://www.developpez.com
Le 01/02/2010 à 23:49
Celle qui m'a sauté aux yeux alors qu'elle n'est pas dans les réponses tout de suite en lisant la question :
> Rester bloqué pendant 1/2 journée devant un problème et ne pas savoir comment faire pour aborder le sujet avec un collègue
1  0 
deadalnix
Avatar de deadalnix
Membre émérite https://www.developpez.com
Le 02/02/2010 à 0:26
Je suis étonné de voir ce qui moi me saute aux yeux : la conception et les bonnes pratiques.

Design pattern ? MVC ? Abstraction ? metaprogrammation (a non, ça c'est tellement ouf que les langages modernes tronquent) ?
1  0 
metagoto
Avatar de metagoto
Membre éclairé https://www.developpez.com
Le 02/02/2010 à 3:05
Je trouve que les nouveaux programmeurs manquent d'expérience
1  0 
Avatar de
https://www.developpez.com
Le 02/02/2010 à 3:06
pour ma part j'ai surtout remarque le cote faire du compliquer pour ce faire remarquer. Du genre développer dans un langage obscure en version alpha qui est aussi stable qu'un flanc. Et aussi l'oublie systematique de commentaires et de nom de variables explicitent.

Code : Sélectionner tout 
1
2
3
4
5
6
7
a = 0;
b = c;
//test
if(a == 2 && c == a){
print "ok";
}
j'ai toujours envie de mettre des claques !
1  0 
iberserk
Avatar de iberserk
Membre expert https://www.developpez.com
Le 02/02/2010 à 8:40
Clairement rester bloquer 1/2 jours sur un problème sans rien demander à personne de peur de se faire mal voir... bien dommageable (au bout de 2 jours, l'équipe n'a cependant pas fait son boulot, un minimum de suivi est nécessaire...

Ce qui me choque surtout est le niveau vraiment ridicule en SQL des BAC+5...
1  0 
naholyr
Avatar de naholyr
Membre régulier https://www.developpez.com
Le 02/02/2010 à 8:52
Mes réponses vont fortement varier en fonction de l'individu, en tous cas surtout en fonction de son emplacement sur la ligne "timide ... extraverti" Les mots "timide" et "extraverti" ne sont peut-être pas totalement représentatifs, mais je vais préciser ma pensée.

L'"extraverti" aura la plupart du temps tous les défauts cités, puisqu'il est trop fort pour avoir besoin d'aide, trop fort pour suivre des standards pourris (les siens sont mieux), trop fort pour avoir besoin de mettre des commentaires, etc...
Comment le détecter ? C'est celui qui va remettre souvent les choix en question, et avoir tendance à déclarer que tout est pourri (en gros, à part ce qu'il a développé lui-même à 14 ans, tout est de la merde). Avec le temps ça deviendra un excellent élément, un dév d'élite, mais il faut qu'il se prenne quelques claques avant Il est impératif de bien le surveiller car il va développer vite, mais sera incapable de tenir sur le long terme (ignorer tel ou tel bug car "pas intéressant" par exemple, ce qui forcément complique la maintenance), et l'existence d'un "responsable qualité" du projet est indispensable pour cadrer ce type de débutant trop sûr de lui.
L'égo surdimensionné est un problème classique pour le programmeur, nous devons toujours lutter contre...

Le "timide" lui en revanche n'a pas ce problème d'égo, mais parce qu'il n'ose pas déranger ne va jamais communiquer. Ça c'est un problème commun à tous les débutants à mon avis, l'absence de communication pour une raison ou pour une autre (soit parce qu'il sait mieux que les autres, soit parce qu'il ne veut pas déranger, soit parce qu'il a peur de poser des questions con, dans tous les cas c'est une composante commune je crois).
Pour éviter ce travers il est indispensable de prendre les devants en :
* Rédigeant des documents de conseil, conception technique, standards de qualité, etc...
* Allant régulièrement le voir pour vérifier son avancement et vérifier qu'il ne reste pas bloqué sur un problème à la con.
* Le rassurer, lui répéter qu'il ne doit pas avoir peur de poser des questions vraiment stupides, et ne pas l'enfoncer quand on lui parle d'un point technique et qu'il ne semble pas comprendre : "ah oui désolé, c'est normal que tu ne saches pas si je ne t'en ai pas parlé avant, tiens vas voir par là tu auras de la doc sur ce point...".

Un problème sous-jacent qui n'est pas posé ici : les programmeurs non débutants ont aussi souvent les mêmes défauts (ne pas poser de question, dériver sans prévenir, rester bloqué sur un problème), donc je ne suis pas sûr que ces défauts soient un problème d'expérience. La seule différence *devrait être* (parce qu'hélas ça n'est pas toujours le cas, je suis bien placé pour savoir qu'on a beau savoir qu'il ne faut pas rester 1/2 journée sur le même problème sans avancer, on le fait parfois quand-même quand on est pris dans le feu de l'action) que le programmeur expérimenté saura prendre du recul et s'arrêter pour s'auto-juger et détecter ses erreurs de comportement afin de les corriger.

L'auto-repair c'est un truc long à acquérir

Bref, ce n'est que mon très humble avis, que je pense très caricatural, mais j'espère qu'il permettra de poser les bases d'un débat intéressant avant que la discussion ne dérive en défouloir anti-noobs
1  0 
smehdi21
Avatar de smehdi21
Candidat au Club https://www.developpez.com
Le 02/02/2010 à 9:40
Bonjour.
etant un programmeur débutant, je dirai que le probléme majeur, c'est de vouloir faire vite pour ne pas etre à la traine de ses collegues et impressioner ses superieurs par sa rapidité, et finalement je me retrouver avec du code pourri que j'arrive pas à maintenir.
aussi un autre point c'est de ne pas savoir prevoir le tps necessaire à telle ou telle tache ...
1  0 
nasty
Avatar de nasty
Membre averti https://www.developpez.com
Le 02/02/2010 à 9:48
Je rejoins smehdi21
C'est vrai qu'en tant que jeune développeur, on cherche a faire bien et si on le fait tout seul c'est mieux, mais je me rappelle avoir passé quelques heures sur des problèmes bidons.
Et je pense que connaitre les erreurs des anciens jeunes développeurs peut aider les nouveaux jeunes développeurs, en les évitant!
Cordialement
Nasty
1  0 
galel
Avatar de galel
Membre actif https://www.developpez.com
Le 02/02/2010 à 9:51
Citation Envoyé par metagoto Voir le message
Je trouve que les nouveaux programmeurs manquent d'expérience
hihi
1  0 
Louis Griffont
Avatar de Louis Griffont
Inactif https://www.developpez.com
Le 02/02/2010 à 10:43
Pour moi, la plupart des soucis viennent de l'intégration du "nouveau" dans l'équipe. Et n'est pas forcément du au "nouveau" justement !

Je pense que beaucoup d'entreprise minimise l'impact de l'arrivée d'un "nouveau" sur l'équipe en place (certains vont se sentir en danger, d'autres se sentir minimiser, ...) et cela peut créer une hostilité, un ressenti vis à vis du "nouveau" qui aura déjà pas mal de stress en arrivant.

J'ai mis "nouveau" entre guillemets car je pense que l'on retrouve les mêmes problèmes que le "nouveau" soit sans expérience ou que ce soit un "confirmé". Je pense que la préparation de l'équipe est primordiale pour que tout se passe bien. Plus le "nouveau" se sentira bien accueilli, plus rapide sera son adaptation. Maintenant, il est important de vite cerné la personnalité du nouvel arrivant "grande gueule", "timide", "je sais tout et mieux que tout le monde", "pourvu que je ne fasse pas de conneries", ... Bref, quelle que soit la personnalité du "nouveau" il me semble impératif de bien l'encadrer et de le mettre en confiance.
1  0 
Commenter Signaler un problème