En tant qu’ingénieur logiciel junior, je parcourais toujours les commentaires de révision de code reçus pour apprendre à devenir un meilleur codeur. Mais lorsque le moment est venu pour moi d'essayer ma première révision de code, j'ai réalisé que mon expérience ne m'avait pas préparée à être de l'autre côté.
J'ai développé un cas grave de syndrome d'imposteur, qui a connu une spirale descendante avec des questions: dois-je commenter cette ligne de code ou ne vaut-elle pas la peine? Devrais-je trouver des articles pour appuyer chaque commentaire? Vais-je planter le site en l'approuvant? Vont-ils me détester? D'accord, j'avoue que je spirale assez rapidement. Mais après avoir parlé à des collègues, je savais que je n'étais pas seul dans mes soucis.
Les ingénieurs informaticiens débutants peuvent être confrontés à la révision de code avec une hypothèse analogue à celle-ci: «Vous savez lire un livre pour savoir comment écrire un livre, ce qui est faux», déclare Jessica Rudder, ingénieure expérimentée chez GitHub.
La révision du code entraîne des attentes et le processus peut être éprouvant pour les nerfs. J'ai donc interrogé sept autres ingénieurs en logiciel pour recueillir des conseils sur la manière de créer un état d'esprit critique.
1. Réfléchissez à l'impact global
En règle générale, une bonne demande d'extraction (PR) ne devrait affecter qu'une partie confinée de la base de code. Cependant, la portée limitée ne devrait pas vous empêcher de penser au changement de code dans le contexte de la base de code plus grande.
Nigel Munoz, ancien ingénieur généraliste de The Muse et ingénieur logiciel indépendant, encourage le lecteur à réfléchir à la manière dont ce changement affecte les perspectives les plus grandes et les plus petites. Pour une vue d'ensemble, trouver une dette technique quelconque: rechercher du code répété, non modulaire ou ne respectant pas les conventions standard les plus récentes, ainsi que l’analyse des modifications apportées à l’architecture de la base de code.
Sam Donow, un développeur principal chez Hudson River Trading, estime qu '«il n'y a rien de trop grand ou trop petit pour commenter. Des suggestions de petites améliorations pourraient conduire à de plus grandes améliorations dans plusieurs parties de la base de code. ”
Vous pouvez utiliser un commentaire de relations publiques sur GitHub pour fournir des commentaires positifs ainsi que pour indiquer en quoi le code peut différer des conventions standard du framework React.
Par exemple, lors de l’une de mes propres revues de code, j’ai reçu un commentaire selon lequel certaines propriétés d’un composant React étaient source de confusion, ce qui a suscité des questions plus générales sur la manière dont le composant était utilisé. En fin de compte, j'ai supprimé les propriétés du composant d'origine et créé un composant distinct pour clarifier le comportement de chacun et garantir que les deux peuvent être utilisés à plusieurs endroits.
2. Considérer la sécurité
N'oubliez pas que certaines modifications pourraient avoir un impact plus important que la base de code. Rudder recommande d'évaluer si un utilisateur «pourrait utiliser cette fonctionnalité pour harceler une personne ou utiliser le système de manière abusive». Par exemple, si la nouvelle fonctionnalité de la demande d'extraction inclut une entrée utilisateur, recherchez l'injection SQL, l'accès aux données, la création de scripts entre sites, etc. autres vulnérabilités de sécurité.
3. Focus sur les bugs
Les autres contributeurs au code, aussi robotiques soient-ils, sont des êtres humains, qui risquent de casser ou d'oublier leurs fonctionnalités. Alors, assurez-vous de «revoir les tests avec la même importance que le reste du code», conseille Abhishek Pillai, responsable technique chez Teachers Pay Teachers. "Ils empêcheront l'apparition de nouveaux bogues et serviront de forme de documentation à toute autre personne qui y travaillera à l'avenir."
La lecture des tests peut vous aider à comprendre les fonctionnalités d’une nouvelle fonctionnalité et à visualiser les différents cas qu’elle présentera. L'analyse des tests peut également vous aider à identifier les cas manquants et à rechercher des fonctionnalités ne figurant pas dans le présent PR. Si le code ne contient aucun test et qu'il semble pertinent, il convient de le demander lors de la révision.
Mais les tests ne font pas tout. «Ne faites pas trop confiance au système», prévient Donow. "Ce n'est pas parce que les tests ont été effectués qu'il n'y a pas de bugs."
Vous pouvez également vouloir «exécuter l'application localement pour la tester fonctionnellement et pour vous assurer qu'elle fonctionne. Si cela ne fonctionne pas, il ne sert à rien d’examiner plus avant », déclare Ryan Verner, développeur de logiciels chez 8th Light. Certains réviseurs ne pensent pas que les tests manuels devraient faire partie du processus de révision du code - en partie à cause du temps nécessaire - Verner pense que c'est un moyen rapide de déterminer s'il est nécessaire d'investir plus de temps dans la révision et une stratégie permettant de réduire les coûts. la croissance d'un arriéré de bugs.
4. Être un joueur d'équipe
Le cliché prend un nouveau sens lorsqu'il s'agit de réviser du code. «Prenez le temps de réviser parce que tout le monde est basé sur le code», déclare Verner, qui plaide pour un sentiment de «propriété collective». En tant que réviseur, vous devriez travailler à la protection de l'arriéré de bugs afin qu'il ne s'agrandisse pas avec l'objectif équipe moins de travail sur la ligne.
Pillai utilise des gifs pour célébrer les relations publiques approuvées et prêtes à être fusionnées de ses coéquipiers.
Parallèlement, Charles Luxton, responsable technique chez The Muse, encourage le critique à comprendre et à se rappeler les priorités de l'équipe. Avec les délais serrés et les désaccords qui se multiplient, créez parfois une tâche à effectuer pour l'arriéré qui garantit des améliorations à l'avenir et laissez un commentaire sur le code en question entre-temps être le pansement dont vous avez besoin pour garde ton équipe heureuse.
Enfin, vous demander si le code aurait du sens pour une personne qui vient de rejoindre l’équipe et qui le lisait au cours des premières semaines, aidera à garder votre code lisible et compréhensible.
5. Utiliser le processus d'apprentissage et de partage des connaissances
Le processus de révision donne à toutes les personnes impliquées un endroit pour obtenir plus d'informations sur la base de code, les langages, les frameworks et les meilleures pratiques.
Matt Jeffery, responsable technique chez The Muse, conseille au réviseur de "comprendre l'architecture des modifications. L'une des méthodes consiste à lire les noms de fichiers, car elles aident à donner du contexte. Par exemple, si vous envisagez de modifier la couche d'accès aux données vous savez que vous ne traitez pas avec la logique métier ou l'interface utilisateur. "
Vous pouvez utiliser un commentaire de PR sur GitHub pour partager la documentation.
Lorsque vous apprenez des modifications de code, vous avez également la possibilité de partager des connaissances. «Il est préférable d'expliquer votre opinion et de la documenter», déclare Luxton. Les liens que vous fournissez avec des preuves à l'appui et des articles fiables aident non seulement le réviseur et le rédacteur de code à explorer différentes approches lorsqu'ils prennent une décision finale, mais ils renforcent également leurs connaissances en programmation.
N'oubliez pas que, même si vous gardez ces conseils à l'esprit, passer en revue les informations fournies est une occasion de mettre en pratique vos compétences relationnelles. "Donnez aux gens le bénéfice du doute qu'ils ont réfléchi à leur approche et soulignez différentes possibilités tout en essayant de dissiper la défense", dit Rudder. «Je laisse des commentaires et un commentaire final: voici ce qui est génial, voici ce qui peut être amélioré, voici ce qui doit être changé avant la fusion.»
Avec ce type d'approche, non seulement vous protégerez votre base de code des dettes technologiques, des menaces pour la sécurité et des bogues, mais vous bâtirez également votre équipe.
