Je ne m'appellerais pas un développeur superstar, mais un relativement expérimenté. J'essaie de maintenir la qualité du code à un niveau élevé et je cherche toujours à améliorer mon style de codage, à rendre le code efficace, lisible et cohérent, tout en encourageant l'équipe à suivre des modèles et des méthodologies pour assurer la cohérence. Je comprends également la nécessité d'un équilibre entre qualité et rapidité.
Pour y parvenir, j'ai présenté à mon équipe le concept de revue par les pairs. Deux pouces vers le haut dans github pull-request pour une fusion. Génial - mais pas à mon avis sans hoquet.
Je vois souvent des commentaires d'examen par les pairs des mêmes collègues comme -
- Ce serait bien d'ajouter un espace après
<INSERT SOMETHING HERE>
- Ligne supplémentaire indésirable entre les méthodes
- Le point final doit être utilisé à la fin des commentaires dans les docblocks.
Maintenant, de mon point de vue - le critique examine superficiellement l'esthétique du code - et n'effectue pas vraiment de révision du code. La révision du code cosmétique me semble être une mentalité arrogante / élitiste. Il manque de substance, mais vous ne pouvez pas trop en discuter car le critique est techniquement correct . Je préférerais de beaucoup voir moins de types de critiques ci-dessus, et plus de critiques comme suit:
- Vous pouvez réduire la complexité cyclomatique en ...
- Sortez tôt et évitez si / sinon
- Résumé de votre requête DB dans un référentiel
- Cette logique n'a pas vraiment sa place ici
- Ne vous répétez pas - résumé et réutilisation
- Que se passerait-il s'il
X
était passé comme argument à la méthodeY
? - Où est le test unitaire pour cela?
Je trouve que ce sont toujours les mêmes types de personnes qui donnent les évaluations cosmétiques et les mêmes types de personnes qui, à mon avis, donnent les évaluations par les pairs "basées sur la qualité et la logique".
Quelle est (le cas échéant) la bonne approche de l'examen par les pairs. Et ai-je raison d'être frustré par les mêmes personnes qui survolent essentiellement le code à la recherche d'erreurs d'orthographe et de défauts esthétiques plutôt que de véritables défauts de code?
Si je ne me trompe pas - comment pourrais-je encourager mes collègues à rechercher des défauts dans le code, tout en suggérant des retouches cosmétiques?
Si je me trompe, veuillez m'éclairer. Existe-t-il des règles générales pour déterminer ce qui constitue réellement une bonne révision de code? Ai-je manqué de savoir ce que sont les revues de code?
De mon point de vue - la révision du code concerne la responsabilité partagée du code. Je ne me sentirais pas à l'aise de donner le feu vert au code sans adresser / vérifier la logique, la lisibilité et la fonctionnalité. Je ne prendrais pas non plus la peine de bloquer une fusion pour un morceau de code solide si je remarquais que quelqu'un avait omis un point dans un bloc doc.
Lorsque je passe en revue le code, je passe peut-être entre 15 et 45 minutes pour 500 loc. Je ne peux pas imaginer que ces évaluations superficielles prennent plus de 10 minutes jamais si c'est la profondeur de l'examen qu'elles effectuent. De plus, quelle est la valeur du pouce levé de l'examinateur superficiel? Cela signifie sûrement que tous les pouces n'ont pas le même poids et qu'il doit peut-être y avoir un processus d'examen en deux passes. Un pouce pour les critiques approfondies et un 2e pouce pour le "polissage"?