Après de graves problèmes de qualité au cours de la dernière année, mon entreprise a récemment introduit la révision du code. Le processus de révision du code a été introduit rapidement, sans lignes directrices ni liste de vérification.
Un autre développeur et moi avons été choisis pour passer en revue toutes les modifications apportées aux systèmes avant leur fusion dans le coffre.
Nous avons également été choisis comme "responsable technique". Cela signifie que nous sommes responsables de la qualité du code, mais nous n'avons aucune autorité pour mettre en œuvre des modifications dans le processus, réaffecter des développeurs ou retenir des projets.
Techniquement, nous pouvons nier la fusion en la rendant au développement. En réalité, cela se termine presque toujours avec notre chef qui exige qu’il soit expédié à temps.
Notre responsable est un MBA principalement chargé de créer un calendrier des projets à venir. Pendant qu’il essaie, il n’a pratiquement aucune idée de ce que notre logiciel fait du point de vue commercial et a du mal à comprendre même les demandes les plus élémentaires de ses clients sans les explications d’un développeur.
Actuellement, le développement est effectué dans les branches de développement de SVN, après que le développeur se soit dit prêt, il réaffecte le ticket de notre système de ticketing à notre responsable. Le responsable nous le cède ensuite.
Les revues de code ont créé des tensions au sein de notre équipe. En particulier, certains des membres les plus âgés remettent en cause les changements ("Nous l’avons toujours fait comme ça" ou "Pourquoi la méthode devrait-elle avoir un nom raisonnable, je sais ce qu’elle fait?").
Après les premières semaines, ma collègue a commencé à laisser les choses glisser pour ne pas causer de problèmes avec les collègues (elle m'a dit elle-même qu'après qu'un rapport de bogue avait été signalé par un client, elle était au courant du bogue, mais craignait que le développeur serait en colère contre elle pour le signaler).
De mon côté, je suis maintenant connu pour être un âne pour signaler des problèmes avec le code engagé.
Je ne pense pas que mes normes sont trop élevées.
Ma liste de contrôle en ce moment est:
- Le code va compiler.
- Il y a au moins une façon dont le code fonctionnera.
- Le code fonctionnera avec la plupart des cas normaux.
- Le code fonctionnera avec la plupart des cas extrêmes.
- Le code lève une exception raisonnable si les données insérées ne sont pas valides.
Mais j'accepte pleinement la responsabilité de la façon dont je donne des commentaires. Je donne déjà des points explicables expliquant pourquoi quelque chose devrait être changé, parfois même demandant simplement pourquoi quelque chose a été mis en œuvre de manière spécifique. Quand je pense que c'est mauvais, je souligne que je l'aurais développé d'une autre manière.
Ce qui me manque, c'est la capacité de trouver quelque chose à qualifier de «bon». J'ai lu qu'on devrait essayer de prendre entre mauvaises nouvelles et bonnes nouvelles.
Mais j'ai du mal à trouver quelque chose de bien. "Hé cette fois, vous avez réellement commis tout ce que vous avez fait" est plus condescendant que gentil ou utile.
Exemple de révision de code
Salut Joe,
J'ai quelques questions sur vos modifications dans la classe Library \ ACME \ ExtractOrderMail.
Je ne comprenais pas pourquoi vous avez marqué "TempFilesToDelete" comme statique? Pour le moment, un deuxième appel à "GetMails" lève une exception, car vous y ajoutez des fichiers sans jamais les supprimer, après les avoir supprimés. Je sais que la fonction n'est appelée qu'une fois par exécution, mais cela pourrait changer à l'avenir. Pourriez-vous simplement en faire une variable d'instance, nous pourrions alors avoir plusieurs objets en parallèle.
... (Quelques autres points qui ne fonctionnent pas)
Points mineurs:
- Pourquoi "GetErrorMailBody" prend-il une exception en tant que paramètre? Ai-je oublié quelque chose? Vous ne lancez pas l'exception, il vous suffit de la transmettre et d'appeler "ToString". Pourquoi donc?
- SaveAndSend n'est pas un bon nom pour la méthode. Cette méthode envoie des mails d’erreur si le traitement d’un mail a mal tourné. Pourriez-vous le renommer "SendErrorMail" ou quelque chose de similaire?
- S'il vous plaît, ne faites pas que commenter l'ancien code, supprimez-le immédiatement. Nous l'avons toujours en subversion.