Avis sur des codes programmés?

Question

Dans notre équipe, nous aimons faire des revues de code, mais parce qu'un contrôle de code peut arriver à tout moment, il est discordant quand vous êtes dans la "zone" de programmation et que vous êtes sollicité pour faire une révision. Vous faites la critique, ce qui est bien, mais il vous faut dix minutes avant de revenir dans la "zone". Je discutais sur la meilleure façon de gérer les besoins de révision de code, mais en minimisant les effets sur la production. J'ai donc eu l'idée d'avoir une sorte d'emploi du temps: un moment où les programmeurs s'associent et parlent du code du jour, mais cela signifie que vous devez attendre le moment de la révision pour le faire. Donc je n'en suis toujours pas sûr.

Alors, comment gérez-vous le mieux les révisions de code tout en réduisant les interruptions?

Merci!

Answer 1

Je pense que l'idée est d'impliquer les gens tôt et souvent. Les revues de code doivent être considérées comme une opportunité de collaboration qui améliorera la conception et la qualité du code. Si les révisions de code ne sont qu'un élément à cocher d'une liste, ou considérées comme une interruption de progression, alors je pense que l'esprit de l'examen est manqué.

Les meilleures critiques de code se produisent lorsque la personne qui écrit le code les recherche réellement. Cela étant dit, nous avons tendance à avoir une règle selon laquelle aucun code n'est archivé tant qu'il n'a pas été examiné. De cette façon, c'est une sorte de révision programmée. Cependant, si vous attendez la fin, vous ne bénéficiez pas d'une révision de code qui contribue à influencer la conception.

Vous pouvez également vous épargner le problème et effectuer une programmation en paire. Vous obtenez la productivité et examiner tous en même temps;)

Answer 2

Vous pourriez le faire comme une sorte de liste de contrôle et laisser les développeurs choisir leur propre meilleur moment. Mais il doit y avoir un vrai délai avec des conséquences réelles sinon il ne sera pas fait. Vous pouvez également faire un jour comme «jour de révision», comme un «examen vendredi» ou quelque chose où vous encouragez les examens à effectuer ce jour-là.

Answer 3

Je vous recommande de les faire quand le programmeur a fini d'ajouter une unité de fonctionnalité, tant que l'estimation de temps pour cette fonctionnalité est inférieure à un jour, cela fonctionne.

Ou mieux encore, faites la programmation en binôme (en vous donnant une révision de code pratiquement continue), mais vous avez toujours des révisions formelles de code, mais moins fréquemment.

Answer 4

G'day,

Je pense ce genre d'un examen impromtu ne doit être utilisé lorsque vous rencontrez des difficultés à comprendre un peu de code. Pour tirer le meilleur parti des révisions de code, elles doivent être programmées à l'avance afin de permettre aux utilisateurs de jeter un coup d'œil à travers le morceau de code examiné.

Il est étonnant comment facilement un critique peut être parlé dans les erreurs manquantes lorsque l'auteur est à leurs côtés. Avec un peu de temps, la plupart des critiques sont plus susceptibles de détecter des erreurs dans le code. Donc, en un mot, planifiez les commentaires à l'avance et assurez-vous que les réviseurs ont suffisamment de temps pour parcourir le code dans leur temps libre.

HTH

acclamations,

Answer 5

Le compromis entre donner aux gens le temps de se préparer à l'examen et réduisant au minimum les perturbations est une question difficile. L'autre fois, faire le bilan, alors que le code est encore «frais», complique encore plus.

J'ai vu un tas de groupes commencent sur la route avec les meilleures intentions, seulement pour avoir le fanent pratique et mourir parce que, sur le net, il est trop perturbateur. La meilleure chose que j'ai vu pour obtenir de nouvelles critiques avec des perturbations minimes au flux est de tourner le temps à fond vers la gauche, et de revoir le code tel qu'il est écrit, par programmation par paire, et par écrire des tests comme une autre forme d'examen. (Avec les tests, les réviseurs doivent se soucier moins de "ça marche du tout?") Un œil supplémentaire sur le code pendant qu'il est écrit est un excellent moyen d'attraper des choses qui prendraient plus de temps à passer en revue, il répand les connaissances beaucoup plus rapidement.

Vous pouvez toujours choisir de faire des examens de groupe de code critique, mais avec moins de commentaires en cours, la chance d'avoir des gens préparés pour un spécial va vers le haut.

C'est une pratique qui est manifestement pas pour tout le monde, mais les équipes que j'ai travaillé qui ont fait TDD et la programmation paire ont tendance à avoir un code plus propre avec un nombre de défauts inférieurs.

Answer 6

Divulgation: Je travaille pour Atlassian, qui vendent Crucible, un code basé sur le Web demande de révision.

Je suis d'accord que la programmation de deux est une pratique précieuse, et qu'elle fournit quelques-uns des avantages de la révision du code (et bien sûr d'autres avantages non liés au code revue!)

Vous pouvez réduire les perturbations causées à leurs auteurs en utilisant un outil de révision du code, de sorte que chaque réviseur procède à l'examen au moment qui lui convient. Cela supprime également le problème de l'auteur qui parle au critique d'accepter le code.

Answer 7

Une façon de le faire est de "revoir les checkins". En d'autres termes, chaque jour, quelqu'un passe en revue tous les checkins et ensuite, s'il y a quelque chose de signalable, s'en va immédiatement et parle et/ou envoie un email au développeur concerné.

Il y a une rétroaction immédiate, la qualité est améliorée car le code est modifié et il est frais dans l'esprit du développeur afin qu'il apprend de lui. J'ai trouvé que cela fonctionne très bien. Une chose que cette approche ne résout cependant pas, c'est quand un développeur vérifie dans un ensemble de code. Il est difficile, avec cette approche, d'examiner plusieurs fichiers entiers à la fois. Cela nécessite une autre approche, une version efficace dont je suis toujours à la recherche.