Comment le code «Goal Tending» doit-il être géré par un responsable du développement?

Permettez-moi d'abord de créer un terme:

objectif du code: vérifier le code le matin, puis examiner silencieusement toutes les modifications apportées par les autres développeurs le jour précédent fichier par fichier, (en particulier les fichiers de code que vous avez développés à l'origine), et corriger le formatage, la logique, le changement de nom des variables, la refactorisation longues méthodes, etc., puis valider les modifications dans le VCS.

Cette pratique a généralement quelques avantages et inconvénients que j'ai identifiés:

• Pro : la qualité / lisibilité / cohérence du code est souvent maintenue
• Pro : Certains bugs sont corrigés car l'autre développeur n'est pas trop familier avec le code d'origine.
• Inconvénient : est souvent une perte de temps pour le développeur qui tend les objectifs.
• Inconvénients : présente occasionnellement des bogues qui provoquent une rage tiraillante par les développeurs qui pensaient avoir écrit du code sans bogue la veille.
• Inconvénients : D'autres développeurs sont aggravés par une piqûre excessive et commencent à détester contribuer au code du gardien de but.

Avertissement: Pour être honnête, je ne suis pas en fait un responsable du développement, je suis le développeur qui s'occupe du "gardien des objectifs".

Pour ma défense, je pense que je fais cela pour une bonne raison (pour garder notre base de code extrêmement grande une machine bien huilée), mais je suis très préoccupé par le fait que cela crée également une atmosphère négative. Je suis également très préoccupé par le fait que mon manager devra résoudre le problème.

Donc, si vous étiez le manager, comment aborderiez-vous ce problème?

MISE À JOUR: Je ne veux pas que cela soit trop localisé, mais certains l'ont demandé, donc peut-être que certains arrière-plans seront éclairants. J'ai été affecté à un projet géant (200K LoC) il y a trois ans, et ce n'est que récemment (il y a 1 an) que des développeurs supplémentaires ont été ajoutés au projet, dont certains ne connaissent pas l'architecture, d'autres qui apprennent encore le langage (C #). Je dois généralement répondre de la stabilité globale du produit, et je suis particulièrement nerveux lorsque des modifications sont étonnamment apportées aux parties architecturales principales de la base de code. Cette habitude est née parce qu'au début, j'étais optimiste quant aux contributions d'autres développeurs, mais ils ont fait beaucoup trop d'erreurs qui ont causé de graves problèmes qui ne seront découverts que des semaines plus tard, où le doigt serait pointé vers moi pour avoir écrit du code instable. Souvent, ces "

Cela ressemble à ce que vous faites est fondamentalement équivalent à une révision de code, sauf que plutôt que de fournir des commentaires au développeur, vous apportez toutes les modifications que vous suggéreriez dans une révision de code. Vous feriez presque certainement mieux de faire un examen du code réel où vous (ou quelqu'un d'autre) fournissez des commentaires au développeur d'origine sur les problèmes de qualité du code et les bogues évidents et demandez au développeur d'origine de les corriger. Cela maintient la qualité du code, mais cela aide également le développeur à se familiariser avec le code d'origine et ses pièges et à améliorer les futurs changements de code. De plus, il n'a pas l'inconvénient de provoquer une «rage tiraillante» lorsqu'un bug est introduit silencieusement ou de faire croire aux autres développeurs qu'on en parle derrière leur dos.

Pour être franc, à mon humble avis, c'est une idée terrible.

Je m'attendrais à ce que le moral tombe dans le caniveau, si ce n'est pas déjà fait.

Pour être juste envers vous, vous le reconnaissez.

Les revues de code par les pairs sont très bien, cela met le fardeau sur les développeurs à un seul niveau, au lieu que ce soit un scénario "eux contre nous". (où il s'agit de gestion / leads).

Il peut y avoir certains développeurs que vous devrez peut-être surveiller plus que d'autres, mais une couverture forçant tout le code à passer par vous en premier est ridicule.

Et malgré la façon dont vous pensez que vous êtes bon, il y aura des moments où vous vous trompez, ou "nit picking" et cela ne fera qu'empirer les choses.

Si j'étais le manager, pour résoudre ce problème:

• Examiner les normes et les pratiques de code avec l'équipe, leur remettre une copie des normes de codage
• Code d'examen par les pairs sur une base régulière pour renforcer les normes et les pratiques à suivre
• Appliquez le nitpicking / formatage avec un outil d'automatisation afin que les développeurs soient obligés de suivre les normes
• Débarrassez-vous des mauvais coéquipiers qui refusent de suivre les normes
• Arrêtez d'être le gardien de but

Vos intentions sont bonnes, mais la mise en œuvre est terrible et, comme d'autres l'ont fait remarquer, entraînera un mauvais moral et des tirs embusqués parmi les membres de l'équipe.

Si le projet n'a jamais eu de norme pour commencer, essayez de simplifier la nouvelle norme par étapes au lieu de simplement basculer un interrupteur.

Mauvais juju.

Je ne suis pas responsable du développement, mais si je l'étais, je ne voudrais pas qu'un de mes développeurs touche un code qui ne fait pas partie d'un défaut ou d'une fonctionnalité qui leur est affecté. Période. Si vous voyez un problème avec le code de quelqu'un d'autre, alors portez-le à l'attention du (des) développeur (s) responsable (s), mais ne vous contentez pas de vous plonger et de le corriger vous-même, surtout si vous ne vous êtes pas coordonné avec l'autre développeur ( s) en premier.

Les tâches de nettoyage ne doivent être exécutées qu'après un examen formel du code par l'équipe, et uniquement par le ou les développeurs à qui ces tâches ont été affectées.

L'initiative est bonne en général, mais parfois elle peut vous mordre le cul. Si vous introduisez des bogues dans c'était le code de travail, vous pouvez rapidement être désireux que vous auriez choisi un cheminement de carrière.