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

Le , par Amine Horseman, Expert éminent sénior
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 ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse Signaler un problème

Avatar de plaxtor plaxtor - Membre du Club https://www.developpez.com
le 08/01/2015 à 22:59
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.
Avatar de ranzoken ranzoken - Membre actif https://www.developpez.com
le 09/01/2015 à 10:02
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
Avatar de landry161 landry161 - Membre éprouvé https://www.developpez.com
le 09/01/2015 à 10:27
Citation Envoyé par Amine Horseman Voir le message


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.

Citation Envoyé par Amine Horseman Voir le message

ajouter des commentaires
Avatar de Thorna Thorna - Membre éprouvé https://www.developpez.com
le 09/01/2015 à 10:34
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.
Avatar de michel.bosseaux michel.bosseaux - Membre averti https://www.developpez.com
le 09/01/2015 à 10:37
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.
Avatar de anapurna anapurna - Expert confirmé https://www.developpez.com
le 09/01/2015 à 11:06
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 ...
Avatar de kolodz kolodz - Modérateur https://www.developpez.com
le 09/01/2015 à 11:49
Citation Envoyé par Amine Horseman Voir le message
« 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.
Avatar de albesoft albesoft - Membre du Club https://www.developpez.com
le 09/01/2015 à 12:12
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é...
Avatar de Carhiboux Carhiboux - Expert éminent sénior https://www.developpez.com
le 09/01/2015 à 14:27
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.
Avatar de Heptaeon Heptaeon - Membre habitué https://www.developpez.com
le 10/01/2015 à 18:03
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.
Contacter le responsable de la rubrique Accueil