Faire progresser la pratique de l'examen du code et des tests unitaires

En tant que chef d'équipe gérant un groupe de développeurs sans expérience (et ne voyant aucun besoin) de révision de code et de test unitaire, comment pouvez-vous faire progresser la pratique de révision de code et de test unitaire?

Comment allez-vous créer un moyen pour que la révision du code et les tests unitaires s'intègrent naturellement dans le flux du développeur?

L'une des résistances de ces deux domaines est que "nous sommes toujours serrés sur la ligne de temps, donc pas de temps pour la révision du code et les tests unitaires".

Une autre résistance à la révision du code est que nous ne savons actuellement pas comment le faire. Devrions-nous revoir le code à chaque enregistrement, ou revoir le code à une date spécifiée?

Les membres de votre équipe conviennent-ils réellement que les revues de code et les tests unitaires sont de bonnes choses, mais il n'y a pas de temps pour cela?

Ou essaient-ils simplement de rejeter l'idée avec cette excuse?

Dans le premier cas, la solution consiste à commencer à le faire maintenant . (OK, si vous êtes dans les derniers jours avant une étape importante, vous pouvez peut-être attendre après - mais pas plus.) Nous avions cette situation dans un de mes précédents lieux de travail, où j'étais ingénieur qualité, responsable de l'amélioration des pratiques de codage et qualité générale. Nous avons reporté le début des révisions de code à la semaine prochaine. Un jour, j'ai réalisé que nous faisions cela depuis environ un mois, et continuerons probablement jusqu'à la fin des temps, à moins que j'essaye quelque chose de différent. J'ai donc annoncé la première révision de code pour cette semaine. J'ai dit aux gars "pas de problème si ce sera imparfait, ou si nous ne savons pas encore exactement quoi faire - nous allons juste commencer à le faire, voir comment ça va et améliorer les choses au fur et à mesure que nous apprenons". Cela a fonctionné, du moins jusqu'à ce que je quitte l'entreprise.

Dans le deuxième cas, vous aurez peut-être besoin de plus de formation et d'une discussion ouverte avec l'équipe. Discutez des problèmes de qualité du code, demandez-leur ce qu'ils considèrent comme des problèmes dans le processus de développement (ou leur absence) / dans le code / les tests, etc. Et réfléchissez ensemble sur la façon de les résoudre . Le but ultime n'est pas nécessairement de faire des revues de code - ce ne sont que des moyens, alors que le but est d'améliorer le processus de développement et la qualité de sa sortie. Il se pourrait bien qu'il y ait d'autres problèmes plus douloureux qui pourraient être améliorés plus facilement et apporter plus d'avantages plus rapidement; puis prenez-les d'abord. Ils peuvent même être des changements insignifiants dans l'environnement ou le processus; tous ces éléments amélioreront le moral de l'équipe, établiront une confiance mutuelle et aideront le lien d'équipe.

En fin de compte, vous ne pouvez pas imposer la qualité à quiconque - vous ne pouvez supprimer que les obstacles à la création de qualité . En appliquant des règles strictes et des pratiques obligatoires sans consensus préalable de l'équipe , vous pouvez aliéner l'équipe et finalement empêcher l'amélioration de la qualité que vous visez. OTOH en discutant ouvertement et en recherchant un accord sur les problèmes les plus urgents pour l'équipe et la manière d'améliorer la situation, vous êtes plus susceptible d'obtenir le soutien de l'équipe. Cela fera une différence cruciale dans le maintien de l'effort d'amélioration de la qualité à long terme.

Le problème classique. Jamais assez de temps pour bien faire, toujours assez de temps pour refaire le travail. Jusqu'à ce que les gens commencent à appliquer les meilleures pratiques, il ne semble jamais y avoir suffisamment de temps pour appliquer les meilleures pratiques. D'autant plus que les gains sont invisibles pour les personnes en dehors du développement.

La clé de la révision du code est que vous souhaitez revoir le moins de code possible, le plus rapidement possible. De cette façon, il est plus facile d'obtenir le temps de le réviser, le code est frais dans l'esprit des gens et la mise en œuvre des améliorations suggérées sera plus facile. À l'extrême, vous souhaitez revoir chaque enregistrement. Un bon outil pour automatiser cela est http://code.google.com/appengine/articles/rietveld.html . Il s'agit d'une variante de l'outil que Google utilise en interne pour forcer la révision du code à chaque enregistrement.

Le défi de la révision de code a été décrit il y a des décennies dans le classique The Psychology of Computer Programming . Le problème est que les programmeurs ont tendance à lier leur image de soi à leurs compétences en programmation. Ce qui signifie que chaque fois que les programmeurs sont confrontés à des preuves que leurs compétences ne sont pas à la hauteur, il y a une tendance à les prendre personnellement. Cela peut provoquer de graves conflits. Si vous prenez le développement rapide classique de Steve McConnell, il propose un certain nombre de suggestions sur la façon de mettre en place un processus de révision de code qui réduit les chances d'un tel conflit. (Un élément clé est de s'assurer que la direction ne participe jamais au processus.) Notez que cela réduit les risques de conflit, mais n'empêche pas le conflit de se produire.

Cela dit, les avantages l'emportent de loin sur les coûts. Pour citer une seule mesure, IBM a constaté que la révision du code était le meilleur moyen de trouver et d'éliminer les bogues. Cela ne remplace en aucun cas votre service AQ. Mais cela entraîne beaucoup, beaucoup moins de problèmes à trouver. Et c'est avant de profiter des avantages liés à l'accélération de l'apprentissage, à la diffusion des connaissances, etc.

Ne leur donnez pas la possibilité. Rendre les tests et les revues obligatoires. S'ils ne coopèrent pas, vous pouvez recourir à des tactiques strictes telles que le refus de promotions non testées ou non révisées. Si les choses vont vraiment mal, renvoyez votre pire délinquant.

J'ai vu des cas où une équipe est toujours en retard parce qu'elle corrige toujours des bogues qui auraient dû être détectés par des tests et des critiques. Un peu plus de travail à l'avance permet d'économiser beaucoup plus à long terme, et plus tôt vous alignerez votre équipe, mieux votre équipe s'améliorera.

Malheureusement, cela peut prendre du temps pour vraiment voir les résultats. Pour encourager la pratique, vous pouvez commencer à tracer le taux de rapports de bogues, le temps moyen de correction des bogues et le taux d'implémentation des fonctionnalités. Je trouve généralement qu'après environ six mois de tests et d'avis, ces mesures s'amélioreront et votre équipe les obtiendra enfin.

Introduire tdd contre la volonté des développeurs est difficile. Il est difficile d'apprendre à aimer tdd.

Étant donné que tdd est le plus efficace dans un champ vert (ou difficile, coûteux, inefficace si les tests sont câblés), je commencerais par une petite équipe qui met en œuvre quelque chose de nouveau. Si vous trouvez deux develloppers dans l'équipe qui sont moins opposés à tdd que les autres, c'est un bon point de départ. gardez à l'esprit que la productivité des développeurs tdd souffrira alors qu'ils sont inexpérimentés avec tdd.

Ce développement tdd est un bon point de départ pour une révision de code. Discutez de la façon dont le tdd a influencé l'architecture du programme et comment il facilite la maintenance logicielle.