Quelles sont les erreurs les plus communément commises par de nouveaux programmeurs ? Et comment les éviter ?

**cfranco** · 05/02/2010, 15h57

Envoyé par skawll

Pour ce qui est du français, il faut reprendre les bases. Je n'ai pas de problèmes mais je sais que certains sont très calés dans leur domaines mais incapables d'écrire une phrase sans fautes! Après ça vient aussi du système scolaire mais aussi du bon vouloir de chacun!

C'est même pas tant la question ça... arriver à communiquer correctement, c'est pas juste une question de langue. Je côtoie des gens qui s'expriment dans un Français parfait, avec une grammaire et une orthographe franchement irréprochables, mais qui ont du mal à se faire comprendre... Un grand classique, qui malheureusement amène à des contresens fâcheux parfois, c'est l'emploi de formulations ambiguës dans des consignes.

Par exemple, dans une liste de choses à faire, écrire un truc du genre :

"Si les données sont indisponibles, l'écran affiche les résultats de la dernière requête à la place"

Qu'est-ce que la personne a bien voulu dire ? Qu'il faut afficher les résultats de la dernière requête, ou bien qu'elle voit les résultats de la dernière requête et que c'est une erreur parce qu'il faudrait que le logiciel n'affiche rien s'il n'y a pas de données disponibles ?

Et ça c'est encore plus un problème à l'écrit qu'à l'oral finalement, parce qu'à l'écrit on n'a pas l'intonation de la personne, on n'a pas le contexte dans lequel ça a été dit, etc...

Personnellement, je communique essentiellement en Anglais, toujours par écrit (messagerie instantanée ou messages différés), avec des sous-traitants qui ne sont ni francophones ni anglophones, je serais loin d'affirmer qu'on ait tous une syntaxe parfaite en Anglais, mais le fait est qu'on se comprend parce qu'on prend l'habitude de faire attention à ce qu'on écrit pour ne laisser aucun doute sur le sens du message.

Après, quand il s'agit d'écrire non pas pour communiquer entre développeurs, ou avec le client, mais pour rédiger les textes composant l'interface du logiciel qu'on développe, là c'est une toute autre affaire, et c'est un travail qui - dans notre organisation - ne relève pas essentiellement des développeurs. A ce niveau-là je dirais que c'est un peu chacun son métier.

Invité · 05/02/2010, 16h15

Envoyé par cfranco

Personnellement, ce que je fais, et j'ai constaté que c'était très efficace, c'est que je découpe les documents pour les mettre à disposition de mes développeurs. C'est particulièrement pratique avec les PowerPoint, quand on a une série de schémas et de maquettes de pages, j'en sors un export en PNG, j'uploade le tout dans un message sur le système de gestion de projet (BaseCamp pour ne pas le nommer), ça passe en images directement visualisables.

Chez moi, on généralise Redmine pour exactement la même raison... Mais cela, c'est un sujet différent: l'accès à une information "à jour".

Le recul du français et de l'écrit, à mon avis, c'est un autre problème. Ca concerne d'abord la qualité de l'information transmise : quand on rédige, on est obligé de réfléchir à ce qu'on transmet, et généralement, de bonne idées apparaissent à ce moment. La rédaction est souvent utile au rédacteur. Inversement, quand on lit quelque chose de rédigé, on est obligé de réfléchir, et cela impose d'essayer de comprendre ce qui est dit. Au final, la qualité de l'information s'en trouve améliorée.

Egalement, les notes écrites se conservent. Au delà des documents immédiats d'un projet (qui généralement sont peu ou prou gardés à jour, car c'est du court terme), il y a tout un tas de choses "moins nécessaires", sur le mode de fonctionnement, des outils d'usage général, des parti pris techniques, etc... qui étaient autrefois le sujet des notes internes, et autres technical reports (observe le nombre de découvertes informatiques provenant de ces divers TR).

Le remplacement progressif de ces notes par des bouts de présentation, des échanges verbaux, ou "'semi écrits" (la messagerie instantanée est un excellent exemple de semi-écrit), rend cette information moins réfléchie, et moins pérenne. Sur le long terme, c'est une très mauvaise chose.

Francois

**cfranco** · 05/02/2010, 16h47

Envoyé par fcharton

Le remplacement progressif de ces notes par des bouts de présentation, des échanges verbaux, ou "'semi écrits" (la messagerie instantanée est un excellent exemple de semi-écrit), rend cette information moins réfléchie, et moins pérenne. Sur le long terme, c'est une très mauvaise chose.

Cela dépend, parce que justement, d'une part il y a d'autres manières plus adaptées de transcrire l'information qui est destinée à être pérenne (je pense en particulier ici à tout ce qui relève de tests automatisés), mais en plus de cela, l'oral ou le "semi-écrit" amène justement à se poser la question de ce qui doit être pérenne et de ce qui ne doit pas être pérenne... (et par là même, de se poser la question par la suite du niveau de confiance envers ce qui a été écrit de manière pérenne il y a longtemps, et qui n'a peut-être plus grand rapport avec la réalité d'aujourd'hui)

La conservation de l'information est un gros problème. Ce qu'on en fait, quand on l'a conservée, c'en est un autre.

Une chose aussi, ce qui fait que je communique presque toujours par des moyens "semi écrits" plutôt qu'à l'oral, c'est justement pour une question de pérennité de ce qui a été "semi-écrit". A partir du moment où ce semi-écrit est un remplacement de l'oral, on considère différemment la question de rédiger des documents à durée de vie plus longue : quel en est l'objectif ? A qui est-il destiné ? Suis-je capable de prévoir jusqu'à quand le document sera valide, ou bien à quel moment il faut prévoir de le remettre à jour ?

Dans notre équipe, nous avons presque totalement éliminé les rapports formels, mais cela ne veut pas dire que toute la communication se fait au même niveau. Les choses sont hiérarchisées, suivant le niveau de validité d'un message il ne va pas prendre la même forme. On n'aborde pas de la même manière une information destinée à rester directement disponible tout au long de la vie du logiciel, et à l'autre extrême un conseil sur un détail d'implémentation pour un point ponctuel. Et bien sûr, il y a périodiquement des remontées, dans un sens ou dans l'autre, c'est le rôle de plusieurs personnes et en particulier celui du chef de projet de veiller à cette réorganisation de l'information.

**Lavock** · 05/02/2010, 16h53

Bon, j'ai pas tout lu, mais :

Incapacité d'estimer le temps nécessaire à l'accomplissement d'une tâche

Je vois pas en quoi c'est "une erreur". La plus grande erreur c'est peut-être de leur demander non ? Je connais pas de méthode quelconque, ni d'outils, qui permette une tel chose... Il s'agit, comme c'est précisé, "une incapacité"... Pas encore synonyme "d'erreur" >< !

Et je suis plutôt scandalisé qu'il y en aie qui répondent ça (premier choix quand même oO). Il y a problème de formation ET de fantasme aussi >< ! Bientôt on va se plaindre que les stagiaires aient pas bouclé leurs projets à 100% aussi, et de pas avoir débugé toutes les autres applications de l'entreprise oO ?

Non mais stop foutage-de-g****e aussi... Je sais quels sont les plus noob des 2 entre les 95 personnes qui ont répondu ça et mes copains de promo >< !

**cfranco** · 05/02/2010, 17h06

Envoyé par Lavock

Bon, j'ai pas tout lu, mais :

Je vois pas en quoi c'est "une erreur". La plus grande erreur c'est peut-être de leur demander non ? Je connais pas de méthode quelconque, ni d'outils, qui permette une tel chose... Il s'agit, comme c'est précisé, "une incapacité"... Pas encore synonyme "d'erreur" >< !

Je rebondis, car je suis d'accord avec vous, même si votre formulation va en faire hurler plus d'un...

Le fond du problème de l'estimation des tâches, c'est que ce n'est pas une compétence "tombée du ciel", ni même une compétence qui puisse être acquise au cours de ses études, ni même une compétence qui puisse être acquise par l'expérience.

Ce dont il s'agit, c'est de suivre la méthodologie en vigueur dans l'équipe de développement, et le choix et l'explication de cette méthodologie est du ressort du chef de projet.

Donc de deux choses l'une :

Soit il y a une telle méthodologie (qui vaudra ce qu'elle vaudra...), et alors ce qu'il est possible de reprocher éventuellement au développeur (débutant ou pas), c'est de mal suivre les consignes qu'on lui a donné pour faire son évaluation (et dans ce cas-là c'est un problème qui est déjà traité par un autre choix du sondage...). Mais s'il avait suivi à la lettre la méthode d'évaluation qu'on lui a demandé de suivre, et qu'au final le chef de projet considère que l'estimation était mauvaise, c'est que soit le chef de projet n'a pas compris ce que c'était qu'une estimation, soit que la méthode qu'il a demandé de suivre n'est peut-être pas très efficace...
Soit il n'y a aucune méthodologie prévue dans l'équipe, et c'est à chacun de se débrouiller pour estimer à sa sauce ce qu'on lui demande de faire. Et donc dans ce cas-là, c'est que le chef de projet ne remplit pas son rôle (mais attention, je ne dis pas que ça soit forcément de sa faute non plus, il y a aussi des boites où le poids de la hiérarchie impose de fait au chef de projet de suivre une méthode qu'il sait inadaptée, mais où il n'a pas son mot à dire...)

**Jidefix** · 05/02/2010, 17h07

Faut lever le pied sur le café et la red bull, c'est juste un sondage

**cinemania** · 05/02/2010, 20h12

Exacte ce n'est qu'un sondage, mais je suis néanmoins d'accord avec certains qui hurlent devant le fait qu'on ose prétendre qu'une mauvaise estimation des temps est une erreur de débutant.

Quel chef de projet saint d'esprit demandera t'il a un stagiaire combien de temps il lui faudra pour effectuer une tache ?
Personnellement ne sachant pas ce que valait chaque stagiaire je leur ai fait faire une tâche avec comme révérenciel, le temps que moi je mets.
Une fois cela fait, vous leur faite faire la tache et voyez le temps effectif passé.

Vous avez alors une idée assez précise de ce qu'ils valent par rapport à vous, et vous êtes plus à même d'estimer leur temps "idéal" et leur temps "catastrophique" et de faire une moyenne.

L'erreur est toujours située du coté du chef de projet qui ose demander à un développeur non confirmé combien de temps il lui faudra pour effectuer une tâche, ou pire un stagiaire.
C'est également une raison pour laquelle mes stagiaires ne travaillaient pas sur des matériels sensibles, pas au sens données confidentielles, mais au sens, temps de traitement cours... mais sur des projets de seconde classe que l'on confie traditionnellement à des stagiaire pour se faire les dents.

il faut quand même réaliser que meme un développeur peut largement, même en étant précis habituellement se planter complètement, et sous-évaluer la tâche et le temps, car sa vision globale du problème fausse la donne.
Afin d'effectuer un chiffrage sur les temps moyens de développement, je prend toujours une journée, pour étudier à fond le cahier des charges et me faire une idée du travail à faire et des différentes phases, et des différents sous problèmes afin d'avoir une idée plus précise en temps/développeur.
Cette technique au sein de l'entreprise m'a toujours permis d'avoir des évaluations relativement juste avec générallement entre 2 et 3 jours de plus en guise de sécurité, il m'est meme arrivé de faire des chiffrages détaillés et les fournir avec les différents temps, quand toute une partie nécessitait un développement et un déploiement sur mesure chez le client.

il arrive que parfois, un élément perturbateur vienne alors "retarder" la date de délivrance, mais c'était générallement due à des déplacements non prévus, des enchainements de réunions inutiles pour planifier des réunions pour en planifier encore d'autres... comment perdre une semaine en voiture... plutot qu'a développer.
vive la bureaucratie et la hiérarchie complètement débile qui ne comprend et n'entrave rien aux raisons et à la mécanique bien huilée d'un bureau de développement.

J'en entends déjà certains me dire, oui mais une journée pour évaluer le temps... et alors ? cette journée d'étude était alors facturée au client sur le projet final comme une journée de consulting, ce qui me permettait aussi souvent d'appeler le client pour bien confirmer point par point que ce que voyait écrit dans le cahier des charges initial fonctionnel était bien conforme et correspondait bien à leur vision des choses et surtout leur besoin.
Généralement on comptait même cette journée dans le temps d'élaboration du cahier des charges et l'étude préliminaire, pour les gros projets.
sinon pour les petits je faisait ca en parallèle avec d'autres projets.

Effectivement le problème de la langue est assez génant, quand vous devez expliquer un mémo que vous avez envoyé à tout le monde parce qu'ils ne sont pas fichus de comprendre un traitre mot de ce qui est écrit en français soutenu.
Il ne faut pas oublier que beaucoup ont un vocabulaire particulièrement ... restreint...

Invité · 05/02/2010, 20h19

Envoyé par Lavock

Et je suis plutôt scandalisé qu'il y en aie qui répondent ça (premier choix quand même oO). Il y a problème de formation ET de fantasme aussi >< ! Bientôt on va se plaindre que les stagiaires aient pas bouclé leurs projets à 100% aussi, et de pas avoir débugé toutes les autres applications de l'entreprise oO ?

Non, mais la question se pose quand même... D'un point de vue d'entreprise (de PME dans mon cas), un expérimenté (un gars avec 10-15 ans d'expérience) ca coûte entre 1,5 et 2 fois plus qu'un petit jeune (parfois moins en fait: les jeunes sont gourmands mais les vieux ont faim...). Actuellement, sur le marché, si tu cherches un peu, tu peux trouver des deux. Il y a, dans les faits, une concurrence entre ces deux groupes.

Dans ce contexte, pour l'entreprise, la question est de savoir si on veut trois petits jeunes, ou deux types de 35-40 ans. Vu du point de vue du jeune diplomé, il me semble que le but est de pallier ce ressenti, et la méthode Alizee (c'est pas ma faute à moi), ca n'a jamais convaincu personne (pas plus que le fait d'être scandalisé).

Enfin, moi, j'dis ca, j'dis rien...

Francois

Invité · 05/02/2010, 20h26

Envoyé par cinemania

Quel chef de projet saint d'esprit demandera t'il a un stagiaire combien de temps il lui faudra pour effectuer une tache ?

Leur demander me parait sain... Les croire me parait idiot.

Maintenant, dans toutes les PME, on va très vite demander à des jeunes embauchés (après 6 mois, disons) d'avoir une idée raisonnable du temps qu'il leur faut pour une tâche. Il n'est pas question de faire du chef de projet (qui en général est le codeur principal, ou l'architecte, ou le responsable du lien client) la "nounou" des devs, même jeunes... Du coup, quand on embauche, on est assez vite exigeant sur la capacité à prévoir. Quelqu'un qui se trompe un peu une fois, ou deux, ca roule. Quelqu'un qui à la troisième fois n'a pas l'air d'apprendre...

Les stagiaires, je ne sais pas, j'en prends rarement, en général, ca ne sert à rien...

Francois

**chaplin** · 06/02/2010, 13h50

Envoyé par fcharton

Les stagiaires, je ne sais pas, j'en prends rarement, en général, ca ne sert à rien...
Francois

C'est un peu tranché comme remarque. Il faut laisser la chance à chacun et surtout un stage permet de découvrir un métier, c'est une porte vers le monde de l'entreprise.

J'ai été stagiaire à deux reprises, et un stage m'a permis de faire un diplôme tandis que l'autre m'a permis d'être embauché. Un stage peut déclencher une motivation chez un individu là ou en règle général il s'enfiche

.

Invité · 06/02/2010, 14h31

Envoyé par chaplin

C'est un peu tranché comme remarque. Il faut laisser la chance à chacun et surtout un stage permet de découvrir un métier, c'est une porte vers le monde de l'entreprise.

C'est exact. Je réagissais à la réponse précédente, qui semblait confondre jeunes programmeurs et stagiaires. Un stage, c'est exactement ce que tu dis, un moyen de présenter l'entreprise aux jeunes diplomés. Prendre des stagiaires pour leur faire faire le "vrai boulot" (ce qui devient malheureusement la manie de certaines boites), c'est aller droit dans le mur.

Personnellement, je recherche peu les stagiaires : il n'y a pas de contraintes, ni d'un côté ni de l'autre, pas de salaire, pas de garanties, pas d'obligations.

Je préfère un salaire et une période d'essai, c'est plus franc.

Francois

**lemerite** · 08/02/2010, 08h20

c'est bien pour ça qu'on les appel nouveaux programmeurs

**cladsam** · 10/02/2010, 13h48

Bonjour,

pour moi ce qui est le plus embêtant, qui passe d'ailleurs difficilement avec l'expérience, c'est de mal gérer la documentation technique.
Je travaille sur une techno -SAP- ou le code ne génère pas un exécutable mais soit de nouvelles fonctionnalités -transactions- soit des modifications à des fonctionnalités existantes -pour faire simple disons extensions-.
Les fonctionnalités existantes peuvent être utilisées partout dans le système et ajouter un morceau de code que la documentation ne permet pas de "géolocaliser" ni d'interpréter c'est comme demander au suivant de faire en 3 heures ce qu'il aurait pu faire en 5 minutes parce qu'il se transforme en sherlock holmes et que ce n'est pas élémentaire ...
Donc pour résumé, les débutants souvent ne trouvent pas le juste milieu d'une documentation complète qui ne paraphrase ni le code ni la spécification fonctionnelle.

**Jidefix** · 10/02/2010, 14h20

Envoyé par cladsam

Bonjour,
pour moi ce qui est le plus embêtant, qui passe d'ailleurs difficilement avec l'expérience, c'est de mal gérer la documentation technique.

Mouais personellement je trouve que ce n'est pas spécialement une erreur de débutant. C'est très rare de trouver une documentation humainement compréhensible, même dans un projet relativement vieux.
Ce qui est marrant c'est que là où je bosse, ils ont acheté un outil en exigeant une documentation dans les règles.
Les prestas (qui sont de ma boite mais chut, il ne faut pas le dire) ont bien fourni un tas de papier digne des archives nationales.
Comme tout le monde s'en tapait "tant que ça marche", personne n'a jamais vraiment ouvert les documents. Maintenant on veut reprendre le truc et là... c'est le drame.

Autant décrypter le code source ça ira plus vite

Du coup pas étonnant que les débutant ne s'y mettent pas non plus...

**DrikS** · 11/02/2010, 22h01

Bonjour à tous,

je suis actuellement en Bac+4 d'informatique. Je trouve les propos de certains excessifs. Certains dénoncent l'inexpérience des jeunes arrivant sur le marché (normal, non ?) et d'autres vantent le niveau et l'expérience à toute épreuve des anciens.
Je pense qu'il faut trouver le juste milieu.
Quand j'entends que certains déplorent le niveau en SQL d'un bac+5, je dis attention. Ayant été confronté à la "gestion" d'un SGBD en entreprise durant un stage, j'ai été scandalisé de voir que les administrateurs de base de données ne savaient pas de quoi je causais quand je leur proposais de fragmenter horizontalement ou verticalement une table, indexer intelligemment et non systématiquement, partitionner une table, etc... Les messieurs laissaient faire le travail à Oracle sans se poser la question que depuis la version 9.i on peut faire ce genre d'action. Où est la réduction des coûts ? l'optimisation ? la performance ?

D'un autre côté, les entreprises utilisent de plus en plus de Framework (maison ou autre) ou autres outils de simplification du travail, qui sont rarement enseignées en école. Il est plus demandé de concevoir des petits ou gros projets, de la conception jusqu'au test, en demandant en gros aux étudiants de coder comme des brutes et rendre le travail le plus propre et fonctionnel possible. On ne se soucie donc pas ici de charte de développement ou de quelconque norme. L'adaptation en entreprise est donc une étape des plus normales...

Et pour ceux qui dénigrent le niveau en programmation de la new wave des jeunes pouces, si vous pouviez m'envoyer un message en MP contenant un de vos projets étudiants pour voir qu'elle était votre niveau, lorsque vous étiez à ma place, histoire que je me fasse une idée.

Tout ça pour dire que je ne me retrouve nulle part dans les différents posts.

Cordialement

**dams78** · 12/02/2010, 10h13

Envoyé par DrikS

Bonjour à tous,

je suis actuellement en Bac+4 d'informatique. Je trouve les propos de certains excessifs. Certains dénoncent l'inexpérience des jeunes arrivant sur le marché (normal, non ?) et d'autres vantent le niveau et l'expérience à toute épreuve des anciens.
Je pense qu'il faut trouver le juste milieu.
Quand j'entends que certains déplorent le niveau en SQL d'un bac+5, je dis attention. Ayant été confronté à la "gestion" d'un SGBD en entreprise durant un stage, j'ai été scandalisé de voir que les administrateurs de base de données ne savaient pas de quoi je causais quand je leur proposais de fragmenter horizontalement ou verticalement une table, indexer intelligemment et non systématiquement, partitionner une table, etc... Les messieurs laissaient faire le travail à Oracle sans se poser la question que depuis la version 9.i on peut faire ce genre d'action. Où est la réduction des coûts ? l'optimisation ? la performance ?

D'un autre côté, les entreprises utilisent de plus en plus de Framework (maison ou autre) ou autres outils de simplification du travail, qui sont rarement enseignées en école. Il est plus demandé de concevoir des petits ou gros projets, de la conception jusqu'au test, en demandant en gros aux étudiants de coder comme des brutes et rendre le travail le plus propre et fonctionnel possible. On ne se soucie donc pas ici de charte de développement ou de quelconque norme. L'adaptation en entreprise est donc une étape des plus normales...

Et pour ceux qui dénigrent le niveau en programmation de la new wave des jeunes pouces, si vous pouviez m'envoyer un message en MP contenant un de vos projets étudiants pour voir qu'elle était votre niveau, lorsque vous étiez à ma place, histoire que je me fasse une idée.

Tout ça pour dire que je ne me retrouve nulle part dans les différents posts.

Cordialement

Pour avoir fais mes études supérieur en apprentissage, je suis d'accord avec toi.
Les deux parties ont a gagner, l'entreprise peut former le jeune sur les bonnes pratiques à prendre : travailler en équipe, documenter son code, etc.
En revanche ce qu'on apprend à l'école est souvent basé nouvelles technologie (dernière version de Java, etc) et de ce côté on peut aussi apporter un plus en l'entreprise en disant "voila ce qu'il se fait maintenant".

Et tout ce mélange peut être bénéfique aux deux parties.