Recommandations pour enseigner aux programmeurs débutants un bon style de codage
Je suis un grand fan d'un bon style de codage, produisant un code propre et clair qui fonctionne bien et est facile à utiliser et à intégrer dans des systèmes plus grands. Je crois que nous, les programmeurs, sommes essentiellement des artisans qui devraient être fiers de notre travail, chaque ligne. Je n'aime pas le code qui est mis en forme de manière incohérente, encombré de code expérimental commenté, et regorge de fonctions et de noms de variables inutiles ou trompeurs. Mais j'ai parfois du mal à discuter avec un code comme celui-ci qui fonctionne essentiellement.
Si vous pensez que le style de codage est important, je recherche des recommandations sur les moyens d'enseigner un bon style de codage professionnel aux programmeurs juniors sous moi. Je veux qu'ils soient fiers de leur travail, mais je crains qu'ils semblent satisfaits lorsque leur code fonctionne à peine et ne semblent pas intéressés à produire ce que des professionnels comme moi considéreraient comme du code professionnel. D'un autre côté, si vous pensez que le style de codage n'est pas particulièrement utile, j'accueille vos commentaires et je suis ouvert à reconsidérer mes normes et tolérances.
Je connais les arguments habituels en faveur d'un bon code: compréhensibilité, facilité de maintenance, etc., mais j'aimerais aussi entendre quelques réfutations à des arguments comme "ça marche, que voulez-vous de plus?"
Dans notre industrie, nous pouvons utiliser le compilateur pour masquer une multitude de péchés. Un code propre et un code désordonné peuvent tous deux conduire à des programmes fonctionnant de manière identique, alors la propreté est-elle importante, et si oui, pourquoi?
[Bien qu'il existe plusieurs questions sur le style de codage, je n'en ai trouvé aucune concernant les méthodes d'enseignement et les moyens d'inculquer un bon style de codage aux programmeurs débutants.]
Faites bonne impression
Prenez certains des livres les plus connus, par exemple Clean Code , Code Complete , Coders at Work , The Clean Coder: A Code of Conduct for Professional Programmers etc . ( voir ici pour les listes complètes ) et donnez-leur quelques jours pour en lire un - au travail, dans un bureau privé. Espacez-les, disons 1 livre par mois ou par trimestre. Ils verront de l'effort que ce que vous dites personnellement est vraiment important, pas seulement "la ligne de l'entreprise" à prendre avec un grain de sel. De toute évidence, assurez-vous que la gestion est conforme à cela - vous ne voulez pas qu'ils disent en passant "hein? Qu'est-ce que la personne X jusqu'à? Enfermé là-dedans avec la porte fermée?"
Parallèlement à des cours de formation continus et plus formels sur les dernières technologies.
De plus, comme les choses se font "de la bonne façon", elles ont donné de grands encouragements et même des récompenses. Sinon, il peut s'agir plus d'un environnement négatif, punissant, plutôt que positif, gratifiant. La plupart des gens veulent faire et veulent être connus pour faire "du bon travail" s'ils ont les outils pour le faire.
Pratiquez ce que vous prêchez, Prêchez ce que vous pratiquez
Parlez de code, parlez des bons principes, parlez de nouveaux outils, devenez "connu" pour cela.
Fournissez/supportez/suggérez des screencasts, des vidéos, des peepcodes et tous les tutoriels et classes en ligne que vous pouvez trouver.
Soutenir et suggérer des groupes d'utilisateurs locaux appropriés, y compris ceux sur des sites comme http://www.meetup.com
Si vous êtes au bureau (c'est-à-dire non virtuel), une bonne étagère des livres que vous aimeriez que les gens utilisent est bonne. Trouvez un moyen de faire en sorte que "ce ne soit pas seulement une étagère poussiéreuse dans le coin", mais en la plaçant vraiment en évidence, en déplaçant les livres, etc. Utilisez aussi votre imagination. Peut-être que chaque programmeur reçoit un livre comme "devoirs" par mois et vous avez une réunion mensuelle où ils peuvent "présenter leurs résultats"!
Cela donnera beaucoup plus l'impression que toute conversation de 10 minutes seule et cela vous retirera du rôle de `` critique '' et leur permettra d'apprendre à pêcher par eux-mêmes (plutôt que de leur donner du poisson, vous connaissez l'affaire). Certains juniors trouvent également intimidant de demander aux personnes âgées d'expliquer toujours les choses, alors que parfois tout ce qu'elles veulent vraiment, c'est un peu de temps pour étudier, pratiquer et absorber.
Instiller une culture d'apprentissage et d'excellence
Fondamentalement, vous voulez créer "une culture d'apprentissage et d'excellence" afin de pouvoir mettre en pratique ce que vous enseignez et inspirer les autres à faire de même.
Cela devrait être en conjonction avec les revues de code pour voir si/comment les principes s'appliquent au travail réel effectué. Inversement, les révisions de code effectuées sans ce qui précède peut donner l'impression de fouetter des sessions à l'élève, quelle que soit la bonne intention de l'enseignant.
Tous les programmeurs doivent toujours faire révisions de code avec un programmeur senior avant de valider/fusionner leurs modifications de code.
- Cela donne aux programmeurs seniors une chance de parvenir à un consensus sur les styles qu'ils veulent appliquer (et reconnaître ceux qui ne sont qu'une question de préférence) entre eux.
- Il donne aux programmeurs juniors une chance d'apprendre quelles pratiques sont attendues de leur équipe dès le départ. Dans quelques mois, 90% du code qu'ils rédiger suivront déjà ces pratiques avant la révision du code.
De plus, la plupart des IDE ont des outils que vous pouvez configurer pour appliquer la grande majorité des préférences de style de codage avec de jolis petits soulignements ondulés et des options pour corriger automatiquement le style dans un fichier. Les programmeurs juniors s'en rendront compte assez rapidement.
Je pense que la meilleure façon d'encourager ce comportement des jeunes développeurs est de le pratiquer vous-même et d'être un modèle pour eux. Si possible, vous devez souvent associer le programme avec eux et mettre l'accent sur la qualité du code lorsque vous programmez avec eux. Pendant l'appariement, vous pouvez expliquer et justifier les bons choix de codage au fur et à mesure que vous les faites. Vous pouvez explorer les "pires" options et expliquer pourquoi elles ne sont pas une bonne solution à long terme. Faire partie de ce type de développement de façon pratique est probablement l'un des meilleurs moyens d'enseigner aux nouveaux développeurs l'importance de la qualité du code. Si tous les membres de votre équipe pensent que la qualité du code est importante, ils apprendront également à la respecter.
Il semble que quelque chose d'aussi simple à appliquer qu'une norme de codage ne sera géré que par:
- Embauchez des personnes qui sont d'accord avec vous.
- Examen du code
- Utilisez des applications qui peuvent automatiser ce genre de choses.
- Faire est tout autant une partie de votre travail que de se présenter. Il doit y avoir des conséquences pour ne pas faire votre travail.
Personnellement, j'apprendrais d'un gestionnaire qui en faisait trop une priorité. Concentrez-vous sur ce qui est important et ne soyez pas nerveux. Vous devriez être en mesure de justifier pourquoi, mais il est parfois temps de choisir un standard (qui sait pourquoi un retrait de 4 espaces est meilleur que 5 autres que vous êtes juste mental).
Obtenez un consensus d'équipe sur les normes. Cela améliorera la qualité et le niveau d'adhésion. Ne perdez pas trop de temps dans un débat. Finalement, un leader prend une décision sur la base de la quantité d'entrée.
Donnez-leur une unité de code très mal écrite à modifier (et tester) puis à réécrire (et tester), puis donnez-leur une unité de code très bien écrite avec des tests unitaires à modifier (et tester) et à leur poser des questions sur l'expérience.
Après cela, donnez-leur une liste de normes à lire et refactorisez leur code (de l'exercice précédent) pour les mettre en pratique.
Vous aurez besoin d'une documentation organisée de vos normes avant cela.
Je pense que vous ne devriez pas enseigner un style de codage spécifique pour les raisons suivantes:
Les programmeurs juniors doivent apprendre de leurs erreurs. Ils s'amélioreront continuellement en évaluant leur travail et en effectuant des révisions de code avec des développeurs seniors.
Les directives de codage varient en fonction de la culture d'une entreprise pour laquelle vous travaillez. Je pourrais argumenter contre ce que vous considérez comme un code propre.
Les programmeurs juniors n'ont généralement pas beaucoup d'exposition aux systèmes d'entreprise, et c'est là que le code propre vit normalement.
Très souvent, les professeurs d'université sont coincés dans le monde universitaire depuis des décennies. J'ai personnellement trouvé leurs directives et leurs commentaires plutôt inutiles et médiocres par rapport aux normes actuelles de l'industrie. Certains, bien sûr, sont très bons.
Pour résumer:
Je pense que la solution n'est pas d'enseigner des directives ou des styles de codage spécifiques, mais d'essayer d'expliquer leur importance dans des projets de différentes tailles.
Il n'y a que beaucoup de choses que vous pouvez expliquer en classe et dans les livres.
Les développeurs devront se salir les mains pour voir le réel avantage pour les thèmes eux-mêmes.
Attribuez des développeurs juniors au programme de jumelage, puis passez en revue leur travail et donnez-leur leur avis. Finalement, ils devraient commencer à voir l'avantage.
Il n'y a pas de style de codage miracle qui fonctionnera toujours, comme tout dans l'ingénierie des systèmes.
Le vrai problème est que les gens ne sont pas d'accord sur ce qu'est exactement du code propre. Une fois que vous avez écrit un code parfait avec tous les détails exactement corrects, la prochaine personne va toujours penser que c'est de la merde. Chaque programmeur examine différentes parties du code et trouve des choses qu'il n'aime pas tout en ignorant simultanément toutes les bonnes parties. C'est une partie nécessaire de la programmation, car les programmeurs doivent trouver les mauvaises choses avant de passer au contrôle de version pour la première fois. Les programmeurs peuvent donc facilement reconnaître le mauvais code. C'est juste que c'est différent pour chaque programmeur.
Dans une équipe, cette fonctionnalité va causer des problèmes, s'il y a des règles trop strictes pour les conventions, ou si les gens doivent maintenir et travailler avec du code écrit par d'autres personnes. La meilleure solution consiste à conserver les conventions, mais pas à les appliquer. Et assurez-vous ensuite que tout le monde sait qui est responsable de chaque partie du code.
Il est maintenant difficile d'enseigner aux programmeurs débutants. La plupart des tentatives se terminent par un programmeur junior pensant que son dernier code était en quelque sorte mauvais et que la session d'enseignement est nécessaire à cause de cela. Comme si c'était une punition pour une erreur qui s'était produite auparavant.
Un code propre et un code désordonné peuvent tous deux conduire à des programmes fonctionnant de manière identique, alors la propreté est-elle importante, et si oui, pourquoi?
Une différence entre un code propre et désordonné est si énorme:
- changer un code désordonné est toujours une tâche intimidante, car il n'a généralement pas de filet sécurisé appelé tests unitaires
- le code désordonné a tendance à avoir des fonctions et des classes énormes et très complexes. Essayer de les comprendre est inutile et très difficile
- le code en désordre a généralement des parties de code copiées/collées, ce qui augmente encore la complexité
D'un autre côté, avec un code propre, tout le monde dans l'équipe peut facilement comprendre la logique derrière et ajouter de nouvelles fonctionnalités sans trop d'efforts.
Si c'est important pour vous, utilisez quelque chose comme checkstyle et mettez-le dans un hook de pré-validation. Si le style de contrôle échoue, le code ne peut pas être validé. Checkstyle est assez bon pour donner des messages de rétroaction. Les gens découvriront pourquoi leur code ne répond pas à la norme et ce qu'ils doivent faire pour le faire.
J'ai appris le bon style de codage d'un des développeurs seniors d'un de mes projets passés. Il passe en revue mon code pour chaque validation lors d'une réunion de révision de code et il m'expliquera ligne par ligne si quelque chose peut y être amélioré.
Il parcourt chaque dénomination des variables et des méthodes et explique comment mieux les nommer.
Il passe par chaque méthode et me dit comment rendre plus lisible et plus efficace.
Il était très poli mais son mentorat m'a beaucoup aidé.
Il ne m'a fallu que trois mois pour m'aligner sur lui et maintenant il trouve rarement des erreurs dans mon code.
Je suis la même méthode d'enseignement de mes développeurs juniors et ça marche.
Parlez-leur de la programmation littéraire de D. Knuth.
Je pense que le moment est venu d’améliorer considérablement la documentation des programmes et que nous pouvons mieux y parvenir en considérant les programmes comme des œuvres littéraires. D'où mon titre: "Literate Programming".
Modifions notre attitude traditionnelle vis-à-vis de la construction de programmes: Au lieu d'imaginer que notre tâche principale est d'instruire un ordinateur sur ce qu'il faut faire, concentrons-nous plutôt sur l'explication aux êtres humains de ce que nous voulons ordinateur à faire
Donald Knuth, à propos de programmation lettrée .
À mon humble avis, le fait que l'objectif principal d'un programme informatique est de communiquer des entités intellectuelles à d'autres programmeurs, est un argument décisif pour l'importance du style de codage.
Je pense qu'un aspect sous-estimé du style de codage est qu'il se manifeste naturellement. Quand je vois un code source que j'ai écrit il y a longtemps, je ressens généralement un désir impérieux de percer le continuum espace-temps juste pour me frapper au visage pour les monstruosités (perçues) que j'ai effectuées dans ladite source. Étant donné que vous encadrez des juniors et qu'ils ont tendance à apprendre rapidement (car ils en ont besoin), faites la solution la plus simple possible: permettez-leur d'écrire un mauvais morceau de code (une fois!), Puis faites-leur le maintenir. Il y a de fortes chances que, s'ils sont bons en génie logiciel, ils se repentent de leurs péchés et refactorisent le code correctement. Bien sûr, ne publiez pas leur collection de spaghettis en tant que code de qualité de production, je suis certain qu'il existe de nombreuses opportunités pour qu'un développeur junior écrive quelque chose de petit, presque `` jetable ''.
Il n'y a pas d'école de logiciel comme la vraie vie
DRY est parfaitement logique lorsque vous avez dû modifier cette ligne copiée-collée 4 fois, et vous ne l'avez fait que 3, c'est pourquoi le code déréférence un pointeur nul et l'application se bloque ...
De plus, l'énergie que vous dépenserez à essayer de leur transmettre de "bonnes" méthodologies sera probablement considérable, et il n'est pas certain qu'ils ne la rejetteront pas avec un "Quoi qu'il en soit, cela fonctionne" comme vous l'avez souligné.
Montrez-leur donc dans la pratique que le style de code est important, en démontrant lui aussi sa meilleure lisibilité.
Le support logiciel est bien plus utile pour les programmeurs qu'ils ne le pensent
Je pense que c'est un autre sujet, mais la plupart des gens supposent instinctivement qu'ils écrivent du bon code (je plaide coupable). Donc, réparer le désordre de quelqu'un d'autre peut être bon pour ses habitudes - vous ne pécheriez pas si vous revenez juste de vacances en enfer, non (opinions religieuses à part)?
Je pense que ce serait un excellent moyen de former les nouveaux programmeurs à la technique des conventions de dénomination [c'est la norme pour nommer une variable, une méthode ou une classe]. Pour un meilleur suivi des flux de programmeurs qui touchent le code, il sera facile de les gérer en connaissant les noms pertinents utilisés.
Par exemple: les variables statiques commencent par s, l'argument Variables commence par a, etc.,
J'ai d'abord appris la programmation en recevant un programme bien écrit et en le guidant ligne par ligne. (J'ai beaucoup appris au cours de ces quelques heures que je n'ai pas reçues dans l'ensemble de mon programme d'études.) Essayez la même chose avec eux, en les parcourant dans l'un de vos meilleurs modules en montrant comment et pourquoi il est construit et stylisé de cette façon. Vous pouvez le faire dans une session de groupe.
Si vous le pouvez, jouez un dictateur bienveillant. Selon votre système de contrôle des révisions, vous pourrez peut-être l'utiliser pour vous aider. Cependant, vous pourriez finir par être le goulot d'étranglement dans le processus de développement.
Déployez un vérificateur de style automatisé pour vérifier autant de règles de style que possible. (De nombreuses règles de style de contrôle doivent être transférables entre Java et C++.) Cela vous y mènera à mi-chemin, mais ne remplacera pas les révisions de code. Demander à vos développeurs de réviser le code par les pairs peut aider à réduire la charge .
Si vous implémentez un vérificateur de style automatisé, vous souhaiterez peut-être également implémenter un outil d'analyse de code statique. Cela devrait aider à éliminer certains des bogues qui peuvent être manqués dans les revues de code. Il vous permettra également de vous concentrer sur les problèmes stylistiques plutôt que de rechercher les erreurs couvertes par l'outil d'analyse de code statique. Il peut encore y avoir des cas communs qui doivent être vérifiés.
Développez une liste de contrôle à utiliser par les développeurs avant de vérifier le code. Cela peut contenir d'autres événements que vous souhaitez effectuer avant l'enregistrement. Il est de plus en plus évident que les listes de contrôle peuvent aider à réduire les erreurs. Encouragez les développeurs à créer leur propre liste de contrôle des erreurs qu'ils commettent couramment, afin d'éviter de les répéter.
Examinez le code
Soulignez en particulier les problèmes résultant d'un mauvais style de codage ou empêchés par un bon style de codage.
Faites beaucoup parler de pourquoi c'est important.
Selon le niveau de vos collègues, sachez que vous devez apprendre à écrire du code avant de pouvoir écrire du code complet.
Une idée: montrez-leur à quoi pourrait ressembler du code s'il était délibérément rendu difficile à lire et à comprendre ( http://www.ioccc.org/2011/konno/konno.c est un petit Nice exemple par exemple). Demandez-leur si vous souhaitez recevoir un code comme celui-ci à conserver?
Soulignez l'importance de
un langage informatique n'est pas seulement un moyen d'obtenir un ordinateur pour effectuer des opérations ... les programmes doivent être écrits pour que les gens puissent les lire, et accessoirement pour que les machines s'exécutent.
(citation de SICP )