Mes collègues devraient-ils revoir le code du système de contrôle des sources?

Voilà donc mon histoire: un de mes collègues utilise pour revoir tout le code, hébergé sur le système de révision. Je ne parle pas d'un examen adéquat des changements dans les pièces auxquelles il appartient. Il regarde le fichier de code fichier à fichier, ligne à ligne. Chaque nouveau fichier et chaque modification. J'ai envie d'être espionné!

Je suppose que si le code était déjà hébergé pour contrôler le système, vous devriez au moins le croire comme fonctionnel. Ma question est, peut-être que je suis juste trop paranoïaque et la pratique de réviser le code les uns des autres est bonne?

PS: Nous sommes une équipe de seulement trois développeurs, et je crains que s'il n'y ait plus d'entre nous, collègue n'aura tout simplement pas le temps de revoir tout le code que nous allons écrire.

Je dirais OUI!

Deux raisons rapides à cela:

1) Si le code est en production, vous ne pouvez pas supposer qu'il est correct. Tout changement ailleurs dans le système peut introduire des bogues. Je pense qu'il est très important que le code soit vérifié régulièrement. De cette façon, le refactoring se fait régulièrement, en gardant le code propre et "plus" correct (la mise à jour est probablement meilleure).

2) Être capable de lire du code est une compétence très importante si vous voulez être programmeur. Et c'est une compétence, quelque chose sur laquelle vous devez travailler. Pour tout programmeur qui commence à travailler sur une base de code existante, s'il n'est pas habitué à lire le code des autres, il y a une courbe d'apprentissage abrupte essayant de se mettre à jour avec ce qui se passe.

Je ne pense pas que vous devriez vous sentir espionné. Acceptez toute critique que quelqu'un vous donne (si elle est valable bien sûr). Et n'hésitez pas à donner à d'autres personnes une critique VALIDE. C'est notre façon d'apprendre. Une fois que nous arrêtons d'apprendre (ou que nous voulons arrêter), il y a de gros problèmes.

Si ce collègue donne une rétroaction positive et constructive, c'est une chose fantastique et vous devriez l'apprécier beaucoup.

Ce FERA attraper les bugs que vous ne pensiez pas quand il écrit. Ce FERA vous conduire à l' écriture de code mieux parce que vous savez que les autres verront.

Il serait sain que toute l'équipe fasse des revues de code au lieu d'une seule personne. Idéalement, tout le monde inviterait quelqu'un à revoir son code une fois terminé. Il est utile de le garder informel (éloignez les gestionnaires) et laissez le réviseur vous parler de ses conclusions. Idéalement, le réviseur ne donne que des commentaires et ne modifie pas le code, bien sûr, vous pouvez l'appairer un peu.

Il est vraiment utile d'avoir des normes de codage pour éviter de constamment revoir les discussions sur les espaces blancs et le style de code. Avoir une analyse de code statique sur une machine de génération peut également être utile pour empêcher certaines discussions.

Concernant l'aspect du temps, la théorie est que cela vous fera gagner du temps. Les défauts ultérieurs sont trouvés plus ils deviennent chers, échouent rapidement. La révision du code de pairs peut attraper pas mal de problèmes.

Votre collègue ressemble à un développeur assidu, vous devriez suivre son exemple.

Je regarde notre système de contrôle de version d'une manière similaire. Notre base de code est trop grande pour regarder chaque ligne, mais j'essaie d'obtenir une sensation de haut niveau pour la plupart des changements. Je surveille également les enregistrements les plus susceptibles d'avoir des effets secondaires et les examine ligne par ligne. Pour le temps minimal que je passe à faire cela, le gain est énorme. (Notez également: je ne suis pas le seul développeur de notre équipe à avoir cette habitude.)

Ce type d'examen a tendance à détecter des bogues ou à invoquer des discussions chaque semaine. Cela fait gagner du temps lors de l'AQ. Les discussions vont des meilleures pratiques à la conception d'algorithmes et plus encore. La clé sur ce front est que tout le monde la considère comme constructive.

Personnellement, cela me donne également une meilleure compréhension de ce qui se passe dans d'autres parties de la base de code que je ne touche pas régulièrement. Lorsque d'autres ont besoin d'aide, je peux intervenir plus rapidement. De plus, lorsque de nouvelles idées apparaissent, je peux en profiter plus tôt.

Vous le sentez espionné (!)? Mais du point de vue de votre collègue, je dirais qu'il fait les bonnes choses pour son développement de carrière. Lisez le code des autres et découvrez comment ils conçoivent et implémentent la logique, cela vous rapportera beaucoup!

À mon humble avis, si quelqu'un signale quelque chose de mal dans votre code, vous devez l'accepter et apprendre d'eux comment écrire un bon code

Pendant 6-7 mois, j'ai fait de même. Pas pour espionner, mais pour contrôler la qualité. Chaque ligne du code pour une application développée activement, engagée dans le référentiel central, 2 langues principales, quelques autres langues, d'énormes makefiles pour 4 plates-formes.

C'est une très mauvaise pratique . Un jour, j'ai découvert que je ne pouvais pas tout capturer à cause de la robustesse. Un autre argument contre cela est la subjectivité - tout le monde peut se tromper.

Il est préférable que les développeurs examinent les codes les uns des autres et qu'il y ait quelqu'un d'expérience pour prendre les décisions finales et définir les directions.

Les révisions de code au sein d'une équipe (à l'aide de fisheye , de creuset ou d'autres outils) sont extrêmement importantes et utiles. la seule chose de mieux est la programmation directe par paires pour s'assurer que le code qui pénètre dans le système la première fois est bien pensé et a traversé le cerveau de plus d'une personne.

C'est arrivé une fois dans mon équipe. Malheureusement, cela a entraîné un jeu de blâme. Les gens attendaient continuellement que les autres vérifient le code et essayaient toujours de trouver quelque chose de mal dedans et jouaient le jeu du blâme tout le temps.

J'espère que vous avez un public plus mûr.

C'est une pratique assez courante dans l'industrie. Les entreprises dans lesquelles j'ai travaillé ont des directives très strictes en matière de révision du code. On ne vous laisserait même pas vous engager à moins que le code n'ait été revu.

Ne vous offusquez pas et ne vous sentez pas surveillé. Considérez-le comme un filet de sécurité et une expérience d'apprentissage.

Lors d'un emploi précédent, le développeur principal a regardé et examiné tous les enregistrements et j'ai souvent reçu d'excellents commentaires qui m'ont aidé à devenir un meilleur développeur.

Dans mon travail actuel, je regarde de nombreux enregistrements et il y a trois jours, j'ai trouvé un bogue et j'ai informé le développeur.

Cette pratique va absolument attraper des bugs et améliorer votre équipe entière, si vous l'acceptez.