Discussion :

[Amine Horseman]

Que faut-il enseigner aux apprentis programmeurs ?
Selon un sénior, la discipline est la clé pour avoir un code clair

Dans un billet de blog, un développeur de jeux vidéo chez Ronimo Games, qui avait passé plus de 7 ans à former les nouvelles recrues à l’art de la programmation, partage avec nous sa façon de voir les choses en ce qui concerne le transfert du savoir. Selon lui, la chose la plus importante à enseigner aux apprentis programmeurs n’est ni les algorithmes, ni les mathématiques, ni les autres connaissances techniques. Bien qu’il ne nie pas leur importance capitale, il affirme que « la principale chose dont ils ont besoin d'apprendre est la discipline. La discipline de toujours écrire un code plus clair, la discipline de le refactoriser après les changements, la discipline de supprimer le code inutile et ajouter des commentaires ».

Il explique ensuite que la discipline est nécessaire et c’est la raison pour laquelle il est toujours important pour un apprenti programmeur de faire un stage, car on ne peut l’apprendre qu’en présence d’un bon superviseur qui restera toujours vigilant sur la qualité du code.

Et pour garder cette qualité de code, il conseille aux apprentis programmeurs de faire attention à une série de fautes qu’on répète souvent lorsqu’on débute :

• éviter les fonctions/variables/classes dont le nom ne reflète pas leur réel fonctionnement ;
• diviser une classe si celle-ci fait beaucoup trop de choses à la fois, où si vous ne pouvez pas résumer ce qu’elle fait dans son nom. En effet, cela rendra le code plus clair et facilitera la détection de bugs ;
• éviter de laisser des bouts de code dans les commentaires sans aucune information sur les raisons. S’il s’agit d’un code erroné à corriger, il faut le spécifier. Sinon, il vaut mieux le supprimer carrément ;
• éviter de dupliquer le code en faisant du copier-coller d’une classe à l’autre. Penser à la réutilisation du code en l’incluant dans une fonction ou une classe à part, et ça facilitera la maintenance plus tard.

« La plupart du temps que je passe à la supervision de stagiaires en programmation est consacré à ces sujets. Et non sur l'explication des technologies de pointe ou les détails de notre moteur », conclut-il. Toutes les choses discutées sont « vraiment évidentes », selon lui. Le défi consiste à les appliquer et toujours les garder à l’esprit et non se contenter de juste les connaître. « C’est pourquoi la chose la plus importante c’est que les apprentis programmeurs apprennent la discipline ».

Source : Joost’s Dev Blog

Et vous ?

Êtes-vous d’accord avec cet avis ?

Quelle est la chose la plus importante durant l’apprentissage de la programmation selon vous ?

[plaxtor]

Bonsoir !

En effet je suis d'accord avec ce développeur, le principal dans un code c'est sa clarté, sa facilité à être lu et compris par d'autres personnes.
Étant en classe préparatoire nous avons 2 heures de programmation par semaine, et je vois trop souvent des élèves perdus dans leur propres codes, ou dans celui du corrigé du professeur car ceux-ci ne sont pas assez "évidents". Je me retrouve à constamment expliquer à mes camarades (sans vouloir me vanter ) quelque chose que la structure du code aurait elle-même du expliquer. Malheureusement je crains que l'enseignement est trop aveuglé par le côté "utilisateur" du langage (Python en l’occurrence) et n'est pas fait pour former de 'bons' programmeurs. La discipline est donc de rigueur dans cette matière où pour chaque problème il y a plusieurs bonnes solutions et une infinité de mauvaises solutions.

[ranzoken]

Bonjour,

100% 200% 500% ..... D'accord.
je suis encore novice dans le domaine de la programmation et pourtant ni les 2 ans que j'ai passé à apprendre en autodidacte grâce au forum d'aide,
ni les deux années de cours d'informatiques, ne m'ont appris les "Best Practices".

Ce qui est assez effarant puisqu'au bout de 4 ans je découvre qu'il y a une bonne façon de faire.
Comme ne pas noter ses control : control1,control2,3,4 ... nom de méthode court et clair.

Ensuite pour reprendre "plaxtor" oui l'enseignement n'est pas adapté. j'ai passé deux ans à apprendre des algorithmes,
et de la technique sur du C, C++. Et Pourtant je ne savais pas coder, je ne comprenais pas ce que je devais faire et quand le faire, ou placer telle ou telle méthode.

Personnellement lors de ma première année j'aurais aimé avoir moins de technique, et plus un cours qui nous expliquer les "Best Practices" comment faire de belle factorisations
et en quoi un programme est mieux qu'un autre. et surtout on NE CODE PAS POUR SOI donc il nous faut "La Discipline" pour reprendre le terme du blog.

Cordialement

[landry161]

Et pour garder cette qualité de code, il conseille aux apprentis programmeurs de faire attention à une série de fautes qu’on répète souvent lorsqu’on débute :

• éviter les fonctions/variables/classes dont le nom ne reflète pas leur réel fonctionnement ;
• diviser une classe si celle-ci fait beaucoup trop de choses à la fois, où si vous ne pouvez pas résumer ce qu’elle fait dans son nom. En effet, cela rendra le code plus clair et facilitera la détection de bugs ;
• éviter de laisser des bouts de code dans les commentaires sans aucune information sur les raisons. S’il s’agit d’un code erroné à corriger, il faut le spécifier. Sinon, il vaut mieux le supprimer carrément ;
• éviter de dupliquer le code en faisant du copier-coller d’une classe à l’autre. Penser à la réutilisation du code en l’incluant dans une fonction ou une classe à part, et ça facilitera la maintenance plus tard.

ajouter des commentaires

[Thorna]

Si je suis bien évidemment d'accord avec ce qui est dit plus haut, à la fois dans l'article et les premiers commentaires, je ne peux que m'inquiéter de constater que cette "discipline" n'est guère utilisée/employée par les programmeurs dont je reçois de temps en temps les productions... Il faut dire qu'avec comme seul critère d'exigence le trop bien connu "je veux tout pour hier !", ça n'encourage pas l'usage de bonnes pratiques, quand ça ne l'empêche pas tout bonnement.

[michel.bosseaux]

Définitivement d'accord

J'ai été amené à donner des cours de rattrapage de programmation en javascript à des étudiants en ... infographie (ils en ont besoin pour créer des sites web donc on leur donnait un cours). Ce n'est pas forcément le langage idéal pour commencer, et j'avais donc un public n'ayant pas la façon de penser "programmeur", que le prof principal avait déjà bien égaré avec une méthode "apprenez par vous même en cherchant sur internet, et je corrige après". Et ses corrections n'étaient pas forcément lisibles.

J'ai pu constater en leur redonnant toutes les bases théoriques que ce qui posait le + problème n'était pas le langage lui même, ni même l'algorithmique (car ils étaient capables de décomposer un problème en diverses étapes et de le traduire en code), mais bien l'organisation du code lui même, surtout dans ce langage où il y a du code synchrone ET de l'asynchrone. Ils ne savaient pas quoi mettre où, nommaient leurs fonctions, objets, variables, n'importe comment ... utilisaient mal les fonctions (trop longues, ou inutiles car code utilisé une seule fois, ou non utilisées dans des cas où il aurait fallu ...). Et au final, étaient incapables de trouver un bug tout bête, ou de modifier leur code pour rajouter qqch.

J'ai eu trop peu d'heures avec eux, et ce qui leur a semble-t-il le plus servi dans ce que je leur ai donné comme matériel est le corrigé de deux exercices, bien structurés et sur-commentés.

Si je suis amené à redonner ce cours, au lieu de me concentrer sur la théorie et devoir dévier (comme ça a été le cas ici), j'aborderai directement les sujets qui fâchent. Je serai sans doute plus efficace.

PS : on pourrait penser que je fais un constat d'échec. Pourtant j'ai fait réussir 80% des étudiants, alors que le taux d'échec habituel dans ce cours est de 90%, vu qu'ils ne sont pas programmeur et la méthode de cours de leur professeur principal inadaptée. J'ai donc, selon tous les critères, plutôt bien fait mon boulot. Mais j'en garde quand même le sentiment de m'être planté en beauté tellement le décalage était grand entre ce que j'avais préparé, et ce dont ils avaient réellement besoin.

[anapurna]

salut

je suis d'accord avec le fait d’être discipliné pour réaliser un bon programme mais, car il y a toujours un mais, pour moi le principal et tout de même l’algorithmie qui prime. celle-ci doit être faites de façon strict et le programme ne seras que le simple reflet de cette l'analyse.
il est évident que si vous faites une analyse sur un bout de table, le code qui en ressortiras ne pourras être qu'un brouillon.
une bonne analyse claire, précise et détaillé doit fournir un support pour le programmeur.
celui ci ne devrais s'occuper que de la syntaxe, ce qui limite quelque peut son champs d'intervention.
mais dans la réalité des entreprise, la partie analyse est souvent bâclée (moi le premier) car comme cela à été dis par l'un des intervenant, il nous est souvent demandé de faire l'impossible pour avant hier. De ce fait en résulte une analyse brouillon qui est souvent retranscrit dans les programmes.
effectivement dans ce cas c'est au programmeur de s’imposer une discipline (de fer) afin qu'a la relecture de son code tout parait clair et concis.
Cette discipline viens souvent après un long apprentissage ...

[kolodz]

« C’est pourquoi la chose la plus importante c’est que les apprentis programmeurs apprennent la discipline ».
?

C'est une mauvaise traduction des dire de cette personne !
La phrase d'origine étant

This is why the most important thing that all programming interns learn at Ronimo is not knowledge, but self discipline.

Cela change radicalement le propos final ! Il présente cela comme la plus valus de donne son entreprise à ses stagiaires. Et non, comme ce qui manque dans l'enseignement de jeune ingénieur.

Personnellement, j'aurai tendance à dire que la discipline(ie la rigueur dans l’analyse), c'est quelque chose que tu "cultive". Cela se raffine avec les années d'expériences. Cela fait partie du "savoir-faire" de notre métier. Ce que tu apprends dans la pratique et non pas à l'école.

D'ailleurs, cela rejoins une discutions qu'on certains anciens membres par rapport aux questions des débutants. Où, ce n'est pas la technique qui pêche, mais cette rigueur/discipline :
http://www.developpez.net/forums/d14...cernant-forum/

Cordialement,
Patrick Kolodziejczyk.

[albesoft]

Ayant enseigné le développement pendant une dizaine d'années, je me suis heurté à tous ces problèmes avec mes stagiaires (dont certains étaient pourtant titulaires de diplômes de niveau élevé...)
L'écriture initiale semble "facile" dès qu'un programmeur a un minimum de connaissances techniques du langage qu'il va employer, il a "tout dans la tête" et se lance aveuglément sur son clavier...
MAIS : qu'en sera-t-il quelques mois après ou, pire, dans une équipe de développement lorsqu'il faut "mettre le nez" dans un code mal écrit, non commenté (intelligemment)...
La maintenance évolutive se solde malheureusement trop souvent par une réécriture complète du module en cours, le "décodage" et la compréhension demandant alors plus de temps que la réécriture (avec tous les risques de reproduire les mêmes erreurs que le développeur précédent...)

Je suis tout à fait d'accord avec la nécessité d'être discipliné et d'appliquer de "bonnes pratiques", encore faut-il que celles-ci soient clairement énoncées.
Mon approche pluri-disciplinaire et multi-langages m'a suggéré cette "méthode" :

Avant de se lancer dans le codage, il faut que le raisonnement soit clairement énoncé (en français, inutile d'appendre n PCodes qui ne font que rajouter une traduction supplémentaire). J'évite volontairement le terme d'algorithme, trop réducteur...

Lorsque le raisonnement est clair, il faut l'écrire (et le relire attentivement), le "tout dans la tête" a ses limites évidentes.
A ce stade, préparer un dictionnaire des données (en appliquant, si elle existe, la charte de nommage préconisée par l'entreprise et/ou le projet ou une charte personnelle que l'on appliquera systématiquement dans toutes ses créations, en l'améliorant au fur et à mesure avec les leçons tirées de l'expérience personnelle).

On peut alors structurer le code :

• détecter des portions répétées que l'on regroupera dans des bibliothèques de fonctions, voire des fonctions déjà existantes...)
• clarifier la structure des classes, éviter des codes de plusieurs milliers de lignes dans le même fichier

Ensuite, quel que soit le langage, inscrire les différentes étapes de ce raisonnement sous forme de commentaires.
Il ne "reste plus qu'à" insérer le code entre les commentaires.
Bien entendu, on tiendra compte de spécificités techniques imposées par le langage choisi, mais à ce moment seulement. Ne pas polluer la logique avec des contraintes purement techniques au stade de la réflexion.

Les remarques faites souvent par les stagiaires : on a l'impression de perdre du temps, on sait ce qu'on a à faire, je connais bien mon langage," je le parle couramment"...

Les avantages :

• Dans la plupart des cas, le fonctionnement est correct dès la première exécution
• La maintenance est beaucoup plus facile, le code est structuré selon la logique de son exécution
• Le portage d'un langage à un autre (ou d'un système à un autre) est facilité...

Résultat : les stagiaires qui ont fait l'effort de suivre ces conseils ont "produit" un code plus clair, plus efficace (et, cerise sur le gâteau) ont obtenu de meilleures notes aux épreuves car ils ont aussi eu le temps de répondre intégralement à l'énoncé...

[Carhiboux]

Il me semble que la lisibilité du code, que ce soit en terme de commentaires, de nommage des variable, ou de découpage du code est une notion qui passe souvent à la trappe lors des formations.

Or, ce devrait être un prérequis.

Maintenant, la vérité, c'est qu'un débutant, qui a envie d'apprendre un langage de programmation pensera à tout autre chose que les bonnes pratiques. C'est donc aux sachants de le sensibiliser aux bonnes pratiques, voir à l'obliger à les respecter.

Pour ma part, pendant ma formation, lorsqu'il fallait rendre des projets, j'ai eu trop peu de retour sur la qualité du code, sur le découpage, sur la façon de procéder. On avait une note, plus en fonction de si cela marchait comme attendu qu'en fonction de la qualité du code derrière le capot. Et on a rarement eu de corrections commentées (ben oui, pour pouvoir redonner le sujet d'une année sur l'autre, il ne faut pas distribuer de correction... )

C'est dommage, car on a ensuite tendance à répéter cela en entreprise. Et c'est là que mon maitre de stage m'en a fait baver. Mais avec le recul, je me dit que cela m'a fait un bien fou, et je suis le premier à faire suer les autres sur le sujet maintenant.

[Heptaeon]

Pour moi on peut programmer de manière "dégueux" temps qu'avant le "commit/push" on fait un "refactoring" digne de ce nom. C'est même dans la tendance Lean ou du livre "Clean code" de ne pas s'encombrer trop tôt avec des détails mais de laisser émerger cette clarté une fois que tout fonctionne.

Par contre, il est vrai qu'il ne faut pas confondre "discipline" et "auto-discipline".

Pour moi la discipline c'est suivre les guidelines, les patterns, etc aveuglément. Un peu comme à l'armée.
L'auto-discipline, c'est différent c'est quelque chose qu'on a choisi et réfléchi.

[Saverok]

Les développeurs débutants ont souvent 2 défauts :
- ils veulent aller trop vite et en oublient certaines étapes essentielles telles que l'analyse du besoin métier (est-ce que j'ai bien compris la demande ?), la conception et l'analyse de l'existent (comment mon code va t'il s'insérer dans le code existant ? est-ce que le code existant contient déjà des méthodes que je peux réutiliser ?)
- ils pensent souvent à tort que la quantité du code exprime sa qualité avec les travers que cela implique

Je partage donc bien le point de vu exprimé dans ce billet de blog
Par grand chose à y ajouter

[Ithildine]

Le courage me semble important aussi...
Accepter de mettre à la poubelle une portion de code sur laquelle on a passé du temps et de l'énergie quand on s'est trompé (ne pas s'obstiner) ou quand elle n'est plus tout à fait utile.
Accepter de remettre en cause des choix quand ils s'avèrent incorrects et ne pas essayer de bidouiller le truc pour qu'il rentre dans les clous au détriment de la simplicité et de la lisibilité, là encore, ne pas s'obstiner.
Accepter de ne pas utiliser la super librairie dernier cri quand une classe existante fait très bien l'affaire (erreur que j'ai vu commettre par beaucoup de débutants)
Accepter de faire une modif pénible dans son propre code quand c'est la solution la plus simple pour tout le projet (combien de développeurs ai-je vu argumenter pour refiler le bébé au collègue !).
Accepter de modifier du code que personne ne comprend plus... mais qui tourne en prod et sur lequel un avenant a été vendu...

Coder, ce n'est pas toujours s'amuser et cela donne parfois des sueurs froides... Pour caricaturer un peu, on peut passer de l'euphorie au désespoir par la simple manifestation d'un problème imprévu.

EDIT : orthographe

[kEep OnE]

Chaque programmeur a une "personnalité" quand il code.
Je me situe plus du côté "Just get the shit done" c'est vrai perso (et c'est pas bien parfois). Mais bon je suis programmeur web (auto-troll ) !

[Franck.H]

Je suis complètement d'accord, je met moi-même un point d'honneur à produire du code propre et lisible. Le simple fait de donner des noms clairs au fonctions/procédures/classes et variables, cela documente le code automatiquement. Diviser les fonctions/procédures/classes pour les spécialiser à une tâche précise améliore également grandement la maintenabilité du programme et auto-documente le tout.

[pvincent]

À l'âge où l'on apprend à programmer, il est déjà bien trop tard pour que cette discipline devienne naturelle. En réalité, c'est le respect des règles d'orthographe au moment où l'on apprend à écrire qu'il faudrai réhabiliter. On donne ainsi des habitudes de rigueur dès l'enfance.
Si j'en crois mes collègues universitaires en activité, ce n'est hélas pas le chemin pris par notre Éducation Nationale.

[kolodz]

À l'âge où l'on apprend à programmer, il est déjà bien trop tard pour que cette discipline devienne naturelle.

Quand le service militaire était encore obligatoire, beaucoup de personnes considéraient avoir appris la rigueur pendant celui-ci. Ce qui est l'âge où on apprends à programmer aujourd'hui... En quoi, ce qui était possible hier ne serai plus possible aujourd'hui ?

En réalité, c'est le respect des règles d'orthographe au moment où l'on apprend à écrire qu'il faudrai réhabiliter. On donne ainsi des habitudes de rigueur dès l'enfance.
Si j'en crois mes collègues universitaires en activité, ce n'est hélas pas le chemin pris par notre Éducation Nationale.

Je suis dyslexique, je fait une tonne de fautes d'orthographe et de grammaire. Et pourtant, quand il s'agit d’écrire un programme informatique propre et fonctionnel. Je pense pouvoir faire aussi bien que toutes les autres personnes.
D'ailleurs, résumé un développeur à une personne qui écrit du code qui compile me semble très réducteur. Il est rare de voir un développeur qui n'a qu'à lire une spécification et appliquer à la lettre celle-ci. Où la seule intelligence du développeur serai de savoir faire la traduction du langage formel d'une spécification à celui d'un langage informatique.

D'ailleurs, le blogueur cité explique bien que l'un des problèmes que le développeur sache se qu'il fait et pourquoi il le fait. Ce qui n'est pas selon moi une notion de rigueur. Et la rigueur de la langue française, c'est souvent connaitre et appliquer des règles sans en connaitre les raisons. Je doute que le future de l'informatique soit à mettre entre les mains des personnes qui ont la rigueur d'appliquer "bêtement" ce qu'ils ont appris.

Je préfère avoir un développeur qui a du bon sens et de la logique.

[pvincent]

Quand le service militaire était encore obligatoire, beaucoup de personnes considéraient avoir appris la rigueur pendant celui-ci.

Je l'ai fait, et j'en déduis que nous n'avons pas la même définition de la rigueur: il ne s'agit pas d'imposer un arbitraire aux autres, mais d'acquérir le goût du travail bien fait.

Je suis dyslexique...

Les dyslexiques sont une minorité qui mérite certes notre attention, mais je pense à la majorité des programmeurs potentiels.
Moi-même victime de la "méthode globale", j'ai eu beaucoup de mal à surmonter ce handicap, et je ne souhaite rien de tel aux élèves de nos jours, sans compter le fait que bien souvent, l'orthographe est un critère de jugement qui joue quand on cherche un emploi.
En fait, une formation bien orientée dès le départ est un gain inestimable.

[Zero62]

je suis parfaitement d'accord avec la rigueur qu'il faut absolument avoir pour coder de manière efficace quelque soit le langage,mais les programmeurs ne sont en général pas "câblés " comme cela!!!!.
Il faut donc leur apprendre la rigueur , la patience (aujourd'hui tout doit? aller vite?) pour éviter les survols sans analyse pertinente et les méthodes qui permettent d'obtenir un bon code avec le minimum de bug .
Mais toute chose il est (me semble-t-il )nécessaire d'avoir un cahier des charges fonctionnel béton....ce qui bien souvent n'est pas le cas hélas!!!!! puis de construire un bon vieil organigramme qui pose un peu les choses et avec ces outils simples le code devrait devenir plus lisible.....et moins brouillon!!!!

[Saverok]

Mais toute chose il est (me semble-t-il )nécessaire d'avoir un cahier des charges fonctionnel béton....

Je vais m permettre de faire une citation de mon propre commentaire en réponse :

l'analyse du besoin métier (est-ce que j'ai bien compris la demande ?)

Avec la rigueur, le développeur se pose des questions sur la demande pour s'assurer de l'avoir bien comprise.
Si la spec n'est pas claire, c'est au développeur d'aller voir l'auteur de la spec pour éclaircir le tout.
Bref, on en revient toujours à la rigueur du concepteur / développeur.

Cela ne sert à rien de rejeter la faute sur les autres.
Si un programme est mal codé, c'est la faute du développeur, pas celle des spec.