Quels sont les processus courants de révision de code et qu'est-ce qui est considéré comme mauvais?

Mon entreprise a récemment commencé à faire des revues de code formalisées. Le processus se déroule comme suit: vous soumettez dans un github, demandez une demande de pull, le code est examiné par environ trois personnes, puis si tout réussit, votre code entre.

Le processus semble juste, mais les trois personnes qui effectuent les révisions de code ne semblent pas être justes. Je remarque que lorsque je mets mon code en revue, j'obtiens entre 100 et 200 commentaires. Le premier chiffre pour moi était de 300 commentaires une fois. Bien sûr, vous pensez que ce sont de grands changements, mais cela peut aussi être de très petits changements avec moins de 50 lignes de code (ce qui inclut des tests unitaires). Tous les commentaires sont considérés comme "à faire" et sans argument.

Dans cet esprit, mon principal problème ici est qu'il semble un peu excessif. J'ai parlé au groupe et ils m'ont dit que ce n'est pas parce que j'ai eu tant d'années de développement en php que je suis un "développeur". Bien sûr, cela semble plus blessant qu'improbable. Je remarque également qu'au sein du groupe, ils ne semblent pas produire autant de commentaires et la plupart du temps, ils ignorent ou ignorent les autres commentaires ou suggestions, l'acceptant rarement comme un point valide même si quelque chose est cassé.

Donc ma question est de savoir si c'est juste? Ou commun?

Tous les commentaires sont considérés comme "à faire" et sans argument.

À mon humble avis, c'est le vrai problème, car il n'y a pas de priorisation. Lorsque vous obtenez 100 à 300 commentaires, certains doivent avoir une priorité A (vrais bugs), certains prio B (susceptibles de conduire à des bugs plus tard) et certains prio C (tout le reste). Dites à vos collègues que vous êtes prêt à respecter tous leurs souhaits, mais pour que les changements soient effectifs et que votre temps est limité, insistez sur une priorisation. Ensuite, commencez par fixer le prio A en premier, et si vous avez vraiment le temps d'en avoir plus après, vous pouvez commencer par B (si vous êtes chanceux, votre patron comprendra que la fixation du prio B et C n'est pas si importante et vous donne certaines tâches plus importantes au lieu de perdre votre temps).

Les révisions de code peuvent être un processus de division.

Vous êtes cependant à un carrefour important. Faites une analyse approfondie de leur évaluation. Identifient-ils des problèmes de pioche ou mettent-ils en évidence de graves lacunes dans votre style et votre logique?

Si c'est le premier, je recommanderais de travailler vers une résolution (nouveau travail ou nouveaux processus de révision de code).

Si c'est le dernier, je recommande de faire beaucoup de lecture de code et d'étudier pour essayer de mettre votre code à la qualité professionnelle.

Il semble que vos collègues utilisent le processus de révision du code pour convenir d'une méthodologie ou peaufiner le code. Je viens de commencer à faire des révisions de code comme vous et je remarque que parfois nous discutons beaucoup de choses qui ne sont que des approches d'implémentation ou des améliorations. Ce n'est pas mal du tout dans la mesure du raisonnable (300 commentaires me semblent trop nombreux, cela doit ressembler à un fil reddit)

Peut-être que vous devez vous mettre d'accord sur certaines décisions architecturales concernant le code avant de commencer à l'implémenter ou peut-être êtes-vous simplement d'accord sur les conventions de dénomination, les modèles et les bonnes pratiques afin que vous sachiez tous ce qu'il est considéré comme un "bon code".

Si vous respectez vos normes de code comme vous le dites et que le code fonctionne comme prévu, il ne devrait pas y avoir autant de commentaires, alors soit ils utilisent votre code comme forum, soit ils vous trollent comme il semble que vous pointez.

J'essaierais d'être critique avec moi-même, j'essaierais de participer aux conversations et de voir la raison de tous ces commentaires et peut-être d'en parler de manière constructive pour voir pourquoi ils sont si mécontents de votre code et si vous le pouvez code d'une manière qui rend tout le monde heureux et le travail ne reste pas bloqué dans la révision du code.

Je viens de lire vos derniers commentaires, parfois lorsque vous n'êtes pas d'accord avec le code, vous pouvez le parcourir cent fois et proposer des changements partout qui ne vous rendent pas heureux parce que la vraie raison est que vous auriez pris une décision architecturale différente et vous n'aimez tout simplement pas ce code, peu importe combien de fois vous le refactorisez. Comme je l'ai dit ci-dessus, vous devez peut-être convenir de l'approche du code à l'avance, donc lorsque vous l'écrivez, vous savez ce qu'ils en attendent et donc votre code serait plus raisonnable pour eux.

D'après ce que vous dites, il me semble qu'ils pourraient avoir un parti pris contre les développeurs php, et donc ils essaient de trouver tout ce qui ne va pas avec votre code afin de prouver leur point.

En ce qui concerne l'examen du code lui-même, je crois, comme vous l'avez déjà dit, qu'une telle quantité de commentaires mineurs est moins utile que quelques critiques bonnes et valides. Et bien que j'ai une expérience limitée en ce qui concerne les revues de code, la technique suivante a bien fonctionné pour les équipes dans lesquelles j'ai travaillé dans le passé.

• Tout d'abord, un analyseur de code statique doit être utilisé pour identifier la plupart des problèmes avant la révision du code. Par exemple: l'exécution de votre code via Sonar, Lint ou tout autre bon analyseur de code devrait vous aider à vous débarrasser de la plupart des problèmes mineurs. D'autant plus que vos réviseurs peuvent définir des profils personnalisés pour garantir tout, depuis le placement des parenthèses, les espaces blancs, les commentaires, la dénomination correcte des variables et bien plus encore ...
• Deuxièmement, je semble bien fonctionner si vous divisez les commentaires en différentes catégories. Par exemple, deux catégories où un groupe comprend de petites choses que vous devriez prendre en note et appliquer à l'avenir. Et un deuxième groupe pour les commentaires qui nécessitent une modification immédiate de votre code qui nécessiterait un autre commit et un examen ultérieur. Bien sûr, le nombre de commentaires dans ce dernier groupe devrait être plus petit.

De plus, je dois dire que mes premiers vrais examens de code contenaient également plus de commentaires que je ne le pensais à l'origine. Cependant, je n'ai jamais considéré cela comme une mauvaise chose. Si vous continuez à apprendre de leurs commentaires² et êtes prêt à appliquer ces techniques / meilleures pratiques nouvellement apprises dans vos futures soumissions de code, les commentaires devraient diminuer. C'était sûrement le cas pour moi ;-)

¹ D'après mon expérience, cela se produit souvent car de nombreux programmeurs affirment que php est le langage de programmation le plus mauvais, ayant les programmeurs les plus inexpérimentés qui l'utilisent. Je m'éloigne de cette affirmation car je crois qu'un excellent logiciel peut être écrit dans n'importe quelle langue!

² En supposant que même si les commentaires sont excessifs, une certaine valeur y est

Est-il courant que quiconque obtienne plus de 100 commentaires dans ses revues de code sur une base régulière? Je dirais que non. Est-il courant que les personnes dont la qualité du code «laisse beaucoup à désirer» obtiennent beaucoup de commentaires, absolument.

Cependant, cela dépend aussi des "règles" du processus de révision du code. TOUT LE MONDE a ses propres idées sur la façon dont quelque chose aurait dû être fait. Si votre processus de révision de code permet aux commentaires de prendre la forme "Vous devriez le faire de cette façon plutôt que de cette façon", vous obtiendrez probablement BEAUCOUP de commentaires même pour un code adéquat. Si votre processus vise à détecter des "défauts", le nombre de commentaires doit être beaucoup plus petit.

D'après mon expérience, les critiques qui permettent des "suggestions" pour des méthodes alternatives sont des pertes de temps. Ces «suggestions» devraient être traitées individuellement en dehors du processus d'examen. Les examens de défauts sont plus utiles car ils amènent les gens à se concentrer sur les bugs au lieu de "pourquoi ne l'avez-vous pas fait comme je l'aurais fait?". Il est également plus utile car il est impossible de nier un bug si quelqu'un en trouve un. Ainsi, il n'y a pas de sentiments blessés mais plutôt de gratitude.

MISE À JOUR: Cela dit, certains codes sont tout simplement mauvais, même s'ils sont exempts de défauts. Dans ce cas, le commentaire de révision doit être un seul commentaire qui dit quelque chose comme. "Ce code doit être nettoyé. Veuillez reporter l'examen jusqu'à ce que le code soit discuté avec [votre nom ici]." Dans ce cas, la révision du code devrait s'arrêter jusqu'à ce que le commentaire soit corrigé.

UPDATE2: @User: Discutez-vous de votre code / design avec l'un d'entre eux pendant que vous le développez afin de pouvoir implémenter ce qu'ils recherchent avant de vous lancer dans votre chemin? Êtes-vous en train de changer quoi que ce soit sur la façon dont vous développez du code en fonction de leurs suggestions ou continuez à penser que votre chemin va bien? Apprenez-vous quelque chose de leurs commentaires?

Quand je suis le chef de file d'un projet, c'est mon travail d'être responsable de TOUS les produits de travail. Si j'approuve un produit de travail, je prétends que le produit est acceptable. Je veux avoir la réputation de construire des produits de qualité. Ainsi, j'ai des attentes et n'accepterai pas moins que satisfaisant. En même temps, j'essaie d'enseigner et d'expliquer les raisons de mes préférences. Ces préférences ne sont pas toujours idéales (en particulier aux yeux des autres), mais la plupart de ces préférences proviennent de l'expérience. Habituellement, une réaction pour éviter de répéter les mauvaises. Ainsi, il y a quelques-uns de mes "adeptes" personnels qui sont nécessaires pour obtenir mon approbation, indépendamment du refoulement.

De l'autre côté, vous devez connaître les attentes qui sont nécessaires pour faire approuver vos produits de travail. Vous pouvez être en désaccord, mais comme vous ne semblez pas avoir le pouvoir de passer outre, apprenez ce qui est attendu. Je doute que l'équipe essaie de vous faire échouer. Comme cela les fait mal paraître aussi. À cet égard, démontrez simplement que vous êtes désireux d'apprendre (même si vous ne l'êtes pas), prenez ce qu'ils disent et faites de votre mieux pour vous adapter à leurs préférences et vous les verrez probablement reculer un peu. Peut-être trouvez-vous celui que vous pouvez au moins tolérer et voyez s'ils feront un peu de main pour vous enseigner leurs façons de faire. Qui sait, dans le processus, vous pouvez apprendre quelque chose qui pourrait vraiment faire passer vos compétences au niveau supérieur.

Quelques différences importantes avec notre processus d'inspection d'équipe:

• la base d'une inspection est une liste de contrôle, compilée par toute l'équipe.
• L'accent est mis sur les défauts (présents et futurs), pas sur le style pour le style.
• les 3 inspecteurs (dont l'auteur) s'assoient ensemble pour parcourir les commentaires. Seuls les commentaires avec vote majoritaire restent.

Pour 50 LOC 300 commentaires semblent être un peu excessifs et - wow - 3 critiques pour chaque demande de tirage? Votre entreprise doit disposer de nombreuses ressources.

D'après mon expérience pour un processus de révision de code utile, il doit y avoir quelques règles et / ou directives:

• Priorité des commentaires
• Classification des commentaires (bug, style de code, etc.)
• Architecture / conception convenue à suivre
• Style de code convenu

Si vous n'obtenez pas une priorité des examinateurs, demandez à votre chef de projet / chef d'équipe responsable; la personne responsable des coûts doit avoir une opinion sur les priorités.

Si vous avez une architecture définie, une compréhension commune des modèles de conception que vous utilisez dans votre projet et un style de code convenu, les commentaires de révision ne doivent concerner que les "vrais problèmes" comme les problèmes de sécurité, les bugs involontaires, les cas d'angle non couverts par le spécifié architecture, etc.

Si votre équipe de développement n'est pas d'accord sur les "problèmes de goût" (par exemple si une variable membre commence par "m_"), chaque critique vous forcera à suivre son style, ce qui n'est qu'une perte de temps / argent.

Cela me semble vraiment être un problème de communication. Vous vous attendez à ce que votre code ne soit pas assez mauvais pour mériter 300 commentaires. Les examinateurs semblent penser que vous avez besoin de beaucoup de commentaires. Se disputer d'avant en arrière de manière asynchrone va perdre beaucoup de temps. Heck, écrire 300 commentaires est une perte de temps ÉNORME. Si ce ne sont pas tous des défauts, il est possible en tant que nouveau membre de l'équipe que vous ne connaissiez pas encore le style de l'équipe. C'est normal et quelque chose qui devrait être appris pour accélérer toute l'équipe.

Ma suggestion est de gagner du temps. Accélérez la rétroaction. Je voudrais:

• Faites plus d'examens intermédiaires pour éviter de faire la même erreur et de générer le même commentaire 50 fois
• Asseyez-vous avec un réviseur pendant qu'il examine votre code afin que vous puissiez parler des problèmes à mesure qu'ils surviennent, évitant ainsi de documenter 300 "problèmes" qui seront effacés lors du prochain commit.
• Associez-vous à l'un de ces "vrais" développeurs pendant un certain temps pendant que vous écrivez le code pour voir ce qu'ils feraient différemment

Les gens peuvent s'opposer au jumelage parce que "cela prendra plus de temps" mais ce n'est évidemment pas un problème ici.