Dans mon entreprise, avant la livraison de tout projet, mon patron demande à mes aînés de revoir les programmes écrits par moi ou d'autres membres de l'équipe ou parfois le patron siège également avec nous pour examen.
Je pense que c'est un bon moyen d'acquérir des connaissances, mais parfois, lorsque les programmes fonctionnent bien, ils ne fonctionnent pas de la même manière après examen et je dois réexaminer mon programme.
Ils disent que l'examen aide à optimiser l'exécution du programme et des requêtes, mais pouvons-nous préférer l'optimisation au fonctionnement réel du programme?
Réponses:
"Travailler correctement" est en effet une excellente métrique, mais si vous êtes le seul dans l'équipe capable de déchiffrer ce que vous avez écrit, et donc de le maintenir, le code est presque sans valeur pour l'entreprise à moyen ou long terme.
Un bon code est au moins:
(Certaines de ces exigences se chevauchent, mais sont bonnes à considérer individuellement ...)
Les revues de code ont un objectif au-delà de la partie "travail", qui peut être effectuée par le biais de tests automatiques.
Je sais personnellement que c'est ennuyeux d'avoir quelque chose qui fonctionne en train d'être déchiré et d'avoir à le reconstruire à partir de zéro. Mais, souvent, cela est dû à une mauvaise communication du responsable senior / technique. Donc, si vous pensez que vous devez réécrire trop souvent, la prochaine fois, allez chez le réviseur avant d'écrire une seule ligne et essayez d'obtenir autant d'informations que possible sur ce qu'il attend, dans les moindres détails. Cela pourrait aussi être formidable si l'équipe de réviseurs de code résume leurs attentes dans un document formel auquel chaque développeur peut se référer.
Sur un plan plus positif, une session pourrait également être l'occasion de partager de bonnes pratiques / conceptions.
la source
J'ai interprété votre question comme "Mon code fonctionnel peut-il être massacré dans une revue à un point où il ne compile même plus?" .
Oui il peut. Généralement, lors d'un examen, vous regardez comment votre code fait ce qu'il fait. Lorsque vous souhaitez remettre votre code, vous dites que vous avez terminé une certaine partie du programme.
Vous dites que ça marche. Des tests sont ensuite effectués pour vérifier cela. Un module qui réussit les tests ne signifie pas que le module ne doit plus être touché.
Un module semblant fonctionnel peut toujours être un désastre en attente de se produire, soit au moment de l'exécution, soit dans quelques mois lorsque vous ou quelqu'un d'autre devez effectuer une maintenance sur celui-ci. En modifiant votre code dans une revue et en soulignant ce qui n'allait pas, votre critique essaie (espérons-le) de vous enseigner quelque chose.
la source
Les évaluations par les pairs sont sans aucun doute un excellent moyen d'apprendre. Quelqu'un peut voir quelque chose de différent, il a une expérience différente de vous et devrait pouvoir apporter des améliorations. Cela ne devrait pas être dénigrant, je m'attends à ce que tout développeur soit en mesure de commenter et de critiquer de manière constructive le code de n'importe qui!
Il me semble que certaines de ces "améliorations" apportent des changements décisifs car (comme vous vous en doutez), le développeur de la revue a moins d'expérience avec le logiciel que l'auteur.
Cette tendance est la rétroaction personnelle, peut-être que votre code est difficile à suivre ou à maintenir? Vos avis sont-ils précieux? Absolument! Je peux voir à quel point cela peut être frustrant, d'avoir un code de travail que vos pairs semblent alors casser, vous ne devriez pas être découragé - vous devriez travailler pour protéger votre code contre ces changements.
La question devient alors comment protéger la fonctionnalité de vos programmes afin que vous sachiez que la fonctionnalité fonctionne toujours après avoir terminé vos évaluations. Ma suggestion serait de vous assurer une couverture décente des tests unitaires. De cette façon, chaque fois que vous / votre réviseur / votre successeur change le code, ils peuvent être sûrs que les modifications qu'ils ont apportées sont sûres.
ETA: Je viens de repérer l'un de vos commentaires, je suis sûr que cela va de soi, mais les révisions de code doivent être effectuées avant que l'équipe de test ne mette la main dessus. Sinon, ils ne testent pas le produit final.
la source