Comment mieux réviser le code?


11

Tout d'abord, je crois fermement au processus de révision du code et je veux toujours que quelqu'un d'autre révise mon code. Ma question porte vraiment sur la façon de faire un meilleur travail pour effectuer une révision de code pour quelqu'un d'autre?

Je sais que pour effectuer une révision du code, vous devez avoir une connaissance du fonctionnement du code existant et une connaissance de la norme locale, deux choses que je pense connaître très bien. Je sens toujours que je ne fais jamais assez de révision de code pour les autres. Je sais aussi que certaines personnes semblent faire un meilleur code de révision de travail que d'autres, donc je me demande pour ceux qui sont de grands réviseurs de code quelles sont les techniques que vous utilisez?


3
Pourriez-vous expliquer pourquoi vous avez l'impression de ne pas faire assez bien votre travail? Par quelle métrique?
Mark Canlas


D'accord avec @Mark: révision du code pour l'exactitude, le style, la simplicité, l'efficacité, ...? Êtes-vous capable de repérer les bogues en lisant le code? Êtes-vous capable de repérer des incohérences de style en le lisant? etc.
rwong

Réponses:


5

Il n'y a aucun moyen de faire un meilleur examen du code. La seule chose que vous pouvez faire est de continuer à vous améliorer avec l'apprentissage et l'expérience.

Normalement, les choses que je suis

- Use variables judiciously
- Keep things in scope loose boundaries will generate more errors
- Orient your language of coding in domain specific terms, they make more sense
- Keep loops to minimum 2 for each method if needed
- use ternary operators
- Arrange methods alphabetically
- Keep errors at handling ease
- write less but efficient code

Je pense qu'il y a beaucoup à ajouter.


2
Je ne suis pas sûr que l'organisation alphabétique des méthodes soit une bonne idée. Je dirais que les garder classés par leur fonction serait mieux. Avoir deux méthodes connexes très loin, simplement parce qu'elles sont nommées getSomething et setSomething ne semble pas une bonne idée.
dévoré elysium le

2
TBH, les opérateurs ternaires transforment souvent votre code en quelque chose de plus difficile à comprendre que sans eux (bien que plus verbeux).
dévoré elysium le

2
Je ne suis pas non plus trop sûr de ce que vous entendez par «écrire du code moins efficace mais efficace». Je dirais qu'en général, peu importe combien vous codez, tant que c'est clair - je ne fais pas particulièrement attention à un code efficace la plupart du temps.
dévoré elysium le

3

demandez-vous ce qui fait des autres un bon critique pour vous?

aussi, au fur et à mesure que vous parcourez le code;

  • arrêtez tout ce que vous ne comprenez pas maintenant écrivez qu'un commentaire est nécessaire
  • identifier s'il est conforme aux normes de codage: espaces, crochets, camelCase..etc
  • vérifier qu'il inclut toutes les fonctionnalités
  • faire des tests simples de la logique pour voir si elle satisfait aux conditions aux limites, etc.

1
raison de downvote? critique constructive s'il vous plaît
Ross

2
Capitalisez correctement.
Mark Canlas

1
lol quoi? np bro
Ross

1

Je vise juste

  • expliquer pourquoi un changement suggéré est nécessaire. Faire en sorte de bien comprendre la raison, pas seulement la solution
  • s'accorder sur la mise en forme du code - pour que le code de chacun soit identique / familier
  • partager une liste de traits de code que vous souhaitez conserver. Mettez-le sur un wiki afin que tout le monde ne doive pas faire chaque erreur une fois. Mettez-le à jour fréquemment.

En dehors de cela, "savoir quoi chercher" vient avec l'expérience, la pratique et la lecture.


1
Je suis un grand fan du formatage de code mécanique. Idéalement fait via un préprocesseur lors des enregistrements, afin que les gens puissent éviter la norme officielle si cela les dérange vraiment (l'expérience suggère qu'ils abandonnent rapidement)

1

D'après mon expérience, le meilleur moyen est de laisser l'équipe du trou faire la révision du code. Nous utilisons une liste de diffusion de validation dans chaque projet où vous pouvez suivre toutes les modifications de code apportées au système de contrôle de version. La plupart de nos développeurs se sont abonnés à leur liste de diffusion spécifique au projet car ils sont intéressés par les changements de code.

Quand quelqu'un remarque une mauvaise façon dans le nouveau code source, il explique au committer comment il peut le faire de meilleure façon, si le committer est un stagiaire, ou il commence une discussion à ce sujet, s'il s'agissait d'un committer plus expérimenté.

Bien sûr, cette méthode ne garantit pas que tout le nouveau code est révisé, en particulier dans les moments stressants où aucun membre de l'équipe n'a le loisir de suivre chaque changement de code. De plus, tous les développeurs ne sont pas responsables de veiller à ce que chaque développeur fasse bien son travail, rien que cela ne peut garantir qu'il est examiné. Mais, au moins dans nos équipes, il y a toujours un responsable technique qui est responsable de la qualité technique.

Je suis un vrai fan des revues de code si elles sont conformes aux scores suivants:

  • chaque développeur a la possibilité de revoir tout le code et l'argument à son avis
  • personne n'a le droit d'abuser du code d'autrui
  • non seulement un mauvais code active une discussion mais aussi un bon code
  • les discussions se terminent par des bonheurs pour toutes les personnes impliquées
  • l'examen a lieu presque en temps réel, au moins avant la fin de la fonctionnalité

Ce que j'ai appris, c'est que si vous êtes quelqu'un qui examine chaque ligne de code et pense que vous devez contrôler des choses comme la qualité du code en termes de formatage ou d'efficacité du code, vous êtes vous-même très inefficace parce que vous faites ce que les machines peuvent faire pour tu. Votre objectif devrait être d'utiliser un système d'intégration continue qui contrôle la qualité de construction et de code de chaque contribution de code. Si ce système génère des rapports et les envoie aux contributeurs, tout est parfait.

Je dois admettre que si vous devez revoir le code parce que vous devez contrôler ou classer la qualité d'un programmeur, alors mes suggestions n'ont pas de sens. Dans ce cas, je ne reverrais pas non plus le code source ligne par ligne. Je voudrais revoir des choses comme:

  • y a-t-il des problèmes de sécurité
  • sont les API prévues utilisées
  • le code a-t-il appliqué l'architecture spécifiée
  • at-il écrit des tests utiles (mais seulement s'il était implicite, je devais apprendre)
  • Documentation
  • processus de construction
  • ... et encore plus, probablement

Si vous êtes un développeur expérimenté, vous trouverez certainement toujours des choses comme des boucles que vous pourriez faire avec de meilleures performances. Bien sûr, il est utile d'expliquer aux autres ces connaissances, mais cela ne devrait pas faire partie de la session d'examen. S'il y a des problèmes de performances importants, ce n'est pas parce qu'il (ou elle) a utilisé une variante moins efficace d'un type de liste.

Parce que la question initiale était pourquoi certaines personnes semblent faire un meilleur examen que d'autres personnes, je répondrais que ces personnes font peut-être un aperçu avant le début de l'examen réel, ce qui signifie qu'elles sont probablement préparées elles-mêmes afin qu'elles sachent exactement ce qu'elles veulent examiner. .


1

[Comment] puis-je faire un meilleur travail en effectuant une révision de code pour quelqu'un d'autre?

Posez-leur beaucoup de questions

Je sais que pour effectuer une revue de code, vous devez connaître le fonctionnement du code existant ...

En fait, non, vous n'avez pas besoin de connaître le code à l'avance pour être un bon réviseur.

Il y a quelques emplois, mon employeur a commencé à exiger que tous les enregistrements de code soient approuvés par un réviseur. Je faisais principalement du GUI en C, et l'un des meilleurs critiques pour moi était mon copain Bill. Il était compétent en C, mais n'avait jamais fait beaucoup de travail GUI, et en entrant dans les revues, il n'avait aucune idée de la façon dont mon code était censé fonctionner.

Mais il a posé beaucoup de questions à ce sujet, et avoir à expliquer pour qu'il puisse comprendre ce que mon code a fait et pourquoi a stimulé beaucoup de réflexion de ma part. Cela m'a amené à trouver beaucoup de petits bugs étranges avec des cas de bord, et à considérer également d'autres approches que j'aurais pu adopter. De plus, même si j'écrivais C depuis 22 ans à ce moment-là et pensais que j'étais assez compétent, cela a rapidement amélioré la qualité de mon code.

Même si je n'y travaille plus, je passe en revue les différences avant l'enregistrement et je me demande: "Quelles questions Bill aurait-il à ce sujet?" Et bien souvent, je finis par changer quelque chose.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.