Il y a deux problèmes notables dans la question, la partie délicate et la prochaine échéance . Il s’agit de problèmes distincts: le premier est une question de communication et de dynamique d’équipe, le second est une question de planification et de hiérarchisation.
Avec tact . Je suppose que vous voulez éviter les égos brossés et le refoulement négatif des critiques. Quelques suggestions:
- Avoir une compréhension commune des normes de codage et des principes de conception.
- Ne jamais critiquer ou revoir le développeur , seulement le code . Évitez le mot "vous" ou "votre code", parlez simplement du code à l'étude, détaché de tout développeur.
- Mettez votre fierté dans la qualité du code terminé , de sorte que les commentaires de révision permettant d'améliorer le résultat final soient appréciés.
- Proposer des améliorations plutôt que la demande. Ayez toujours un dialogue si vous êtes en désaccord. Essayez de comprendre l'autre point de vue lorsque vous n'êtes pas d'accord.
- Demandez aux avis d'aller dans les deux sens. C'est-à-dire que la personne que vous avez révisée revoit votre code ensuite. Ne pas avoir des critiques "à sens unique".
La deuxième partie est la priorisation . Vous avez de nombreuses suggestions d’amélioration, mais comme la date limite approche, il ne reste que le temps d’en appliquer quelques-unes.
Eh bien, vous voulez d’abord éviter que cela se produise! Pour ce faire, vous effectuez des révisions incrémentielles continues. Ne laissez pas un développeur travailler pendant des semaines sur une fonctionnalité, puis relisez-le au dernier moment. Deuxièmement, les révisions de code et le temps nécessaire pour mettre en œuvre les suggestions de révision devraient faire partie de la planification et des estimations régulières pour chaque tâche. S'il n'y a pas assez de temps pour examiner correctement, il y a eu un problème de planification.
Mais supposons que quelque chose a mal tourné dans le processus, et vous êtes maintenant confronté à un certain nombre de commentaires de révision, et vous n'avez pas le temps de les mettre tous en œuvre. Vous devez donner la priorité. Ensuite, optez pour les changements qui seront les plus difficiles et les plus risqués à changer plus tard si vous le retardez.
Nommer des identifiants dans le code source est extrêmement important pour la lisibilité et la maintenabilité, mais il est également assez facile et peu risqué de changer à l'avenir. Idem avec le formatage du code. Alors ne vous concentrez pas sur ce genre de choses. Par ailleurs, la santé des interfaces exposées publiquement devrait être la priorité absolue, car elles sont vraiment difficiles à modifier à l'avenir. Les données persistantes sont difficiles à modifier - si vous commencez par stocker des données incohérentes ou incomplètes dans une base de données, il est très difficile de les corriger à l'avenir.
Les zones couvertes par les tests unitaires présentent un risque faible. Vous pouvez toujours les réparer plus tard. Les zones qui ne le sont pas, mais qui pourraient être testées par unité, présentent un risque plus faible que les zones qui ne peuvent pas être testées par unité.
Supposons que vous disposiez d'une grande quantité de code sans tests unitaires et que vous rencontriez toutes sortes de problèmes de qualité du code, notamment une dépendance codée en dur à un service externe. En injectant plutôt cette dépendance, vous rendez le bloc de code testable. Cela signifie qu’à l’avenir, vous pourrez ajouter des tests puis travailler à résoudre le reste des problèmes. Avec la dépendance codée en dur, vous ne pouvez même pas ajouter de tests. Alors allez-y d'abord pour ce correctif.
Mais s'il vous plaît essayez d'éviter de vous retrouver dans ce scénario en premier lieu!