Comment gérer le désaccord dans une révision de code concernant un cas Edge improbable?
Je travaille dans une startup de robotique dans une équipe de couverture de chemin et après avoir soumis une demande de pull, mon code est révisé.
Mon coéquipier, qui fait partie de l'équipe depuis plus d'un an, a fait quelques commentaires sur mon code qui suggèrent que je fais beaucoup plus de travail que je ne le pense nécessaire. Non, je ne suis pas un développeur paresseux. J'adore le code élégant qui a de bons commentaires, des noms de variables, une indentation et gère correctement les cas. Cependant, il a un autre type d'organisation en tête avec lequel je ne suis pas d'accord.
Je vais vous donner un exemple:
J'avais passé une journée à écrire des cas de test pour changer un algorithme de recherche de transition que j'avais fait. Il avait suggéré que je traite un cas obscur qui est extrêmement improbable - en fait, je ne suis pas sûr qu'il soit même possible que cela se produise. Le code que j'ai créé fonctionne déjà dans tous nos cas de test d'origine et quelques nouveaux que j'ai trouvés. Le code que j'ai fait passe déjà nos 300+ simulations qui sont exécutées tous les soirs. Cependant, pour gérer ce cas obscur, il me faudrait 13 heures qui pourraient mieux être consacrées à essayer d'améliorer les performances du robot. Pour être clair, l'algorithme précédent que nous utilisions jusqu'à présent n'a pas non plus géré ce cas obscur et pas une seule fois, dans les 40 000 rapports qui ont été générés, ne s'est jamais produit. Nous sommes une startup et devons développer le produit.
Je n'ai jamais eu de révision de code avant et je ne suis pas sûr d'être trop argumentatif; devrais-je simplement me taire et faire ce qu'il dit? J'ai décidé de garder la tête baissée et de faire le changement même si je suis fortement en désaccord avec le fait que c'était une bonne utilisation du temps.
Je respecte mon collègue et je le reconnais comme un programmeur intelligent. Je suis juste en désaccord avec lui sur un point et je ne sais pas comment gérer le désaccord dans une révision de code.
Je pense que la réponse que j'ai choisie répond à ces critères d'expliquer comment un développeur junior peut gérer les désaccords dans une révision de code.
un cas obscur qui est extrêmement improbable - en fait, je ne suis pas sûr qu'il soit même possible de se produire
Ne pas avoir de comportements non testés dans le code peut être très important. Si un morceau de code est exécuté, par exemple 50 fois par seconde, une chance sur un million se produira environ toutes les 5,5 heures d'exécution. (Dans votre cas, les chances semblent plus faibles.)
Vous pouvez parler des priorités avec votre manager (ou celui qui est le plus ancien responsable de l'unité dans laquelle vous travaillez). Vous comprendrez mieux si par exemple travailler sur les performances du code ou le code à l'épreuve des balles est la priorité absolue, et à quel point ce cas de coin peut être improbable. Votre réviseur peut également avoir une idée biaisée des priorités. Après avoir parlé avec le responsable, vous aurez plus de facilité à (dés) accepter les suggestions de votre critique et vous aurez quelque chose à quoi vous référer.
C'est toujours une bonne idée d'avoir plus d'un critique. Si votre code n'est révisé que par un collègue, demandez à quelqu'un d'autre qui connaît ce code, ou la base de code en général, de jeter un œil. Une deuxième opinion, encore une fois, vous aidera à (dés) accepter plus facilement les suggestions du critique.
Avoir un certain nombre de commentaires récurrents au cours de plusieurs révisions de code indique généralement qu'une chose plus importante n'est pas clairement communiquée, et les mêmes problèmes se reproduisent encore et encore. Essayez de découvrir cette chose plus importante et discutez-en directement avec le réviseur. Posez assez pourquoi questions. Cela m'a beaucoup aidé lorsque j'ai commencé la pratique des revues de code.
Je peux vous donner un exemple de cas d'angle qui n'a jamais pu se produire et qui a provoqué une catastrophe.
Lorsque le Ariane 4 était en cours de développement, les valeurs des latéraux accéléromètres ont été mises à l'échelle pour tenir dans un entier signé 16 bits et parce que le maximum possible la sortie des accéléromètres, une fois mise à l'échelle, pourrait jamais dépasser dépasser 32767 et le minimum pourrait jamais en dessous de -32768 il n'y avait "pas besoin de frais généraux de vérification de plage". En général, toutes les entrées sont censées être vérifiées avant toute conversion, mais dans ce cas, cela tenterait d'attraper un cas de coin impossible.
Plusieurs années plus tard, le Ariane 5 était en cours de développement et le code de mise à l'échelle des accéléromètres latéraux a été réutilisé avec un minimum de tests car il a été "prouvé en utilisation". Malheureusement, la plus grande fusée pouvait s'attendre à des accélérations latérales plus importantes, de sorte que les accéléromètres ont été améliorés et pourraient produire des valeurs 64 bits flottantes plus importantes.
Ces valeurs plus grandes "enveloppées" dans le code de conversion, rappelez-vous aucune vérification de plage , et les résultats lors du premier lancement en 1996 n'était pas bon. Cela a coûté des millions à l'entreprise et a provoqué une interruption majeure du programme.
Le point que j'essaie de faire est que vous ne devez pas ignorer les cas de test car jamais se produisant, extrêmement peu probable, etc.: les normes qu'ils codaient pour appelé pour la vérification de la plage de toutes les valeurs d'entrée externe . Si cela avait été testé et géré, la catastrophe aurait pu être évitée.
Notez que dans Ariane 4 ce n'était pas un bug, (comme tout fonctionnait bien pour chaque valeur possible) - it était un manquement aux normes. Lorsque le code a été réutilisé dans un scénario différent, il a échoué de manière catastrophique, alors que si la plage de valeurs avait été tronquée, il aurait probablement échoué gracieusement, et l'existence d'un cas de test pour cela peut-être ont déclenché une révision des valeurs. Il convient également de noter que, alors que les codeurs et les testeurs sont venus pour certaines critiques des enquêteurs après l'explosion, la direction, l'AQ et la direction ont été laissés à la majorité de la responsabilité.
Clarification
Bien que tous les logiciels ne soient pas critiques pour la sécurité, ni si spectaculaires lorsqu'ils échouent, mon intention était de souligner que les tests "impossibles" peuvent encore avoir de la valeur. C'est le cas le plus dramatique que je connaisse, mais la robotique peut également produire des résultats désastreux.
Personnellement, je dirais qu'une fois que quelqu'un a mis en évidence un cas de coin à l'équipe de test, un test doit être mis en place pour le vérifier. Le responsable de l'équipe d'implémentation ou le chef de projet peut décider de ne pas essayer de résoudre les défaillances détectées, mais doit être conscient qu'il existe des lacunes. Alternativement, si les tests sont trop complexes ou trop coûteux à implémenter, un problème peut être soulevé dans le tracker utilisé et/ou le registre des risques pour indiquer clairement qu'il s'agit d'un cas non testé - qu'il peut être nécessaire de le résoudre avant un changement d'utilisation ou empêcher une utilisation inappropriée.
Puisqu'il n'a pas été traité auparavant, il est hors de portée de vos efforts. Vous ou votre collègue pouvez demander à votre responsable si cela vaut la peine de couvrir ce cas.
Avec des algorithmes complexes, il est très difficile de prouver que vous avez pensé à chaque cas de test qui surviendra dans le monde réel. Lorsque vous laissez intentionnellement un cas de test cassé parce qu'il ne se présentera pas dans le monde réel, vous quittez potentiellement autre cas de test cassés auxquels vous n'avez même pas encore pensé.
L'autre effet qui se produit souvent est lorsque vous manipulez des cas de test supplémentaires, votre algorithme devient nécessairement plus général, et à cause de cela, vous trouvez des moyens de le simplifier et de le rendre plus robuste pour tous vos cas de test. Cela vous fait gagner du temps dans la maintenance et le dépannage sur la route.
En outre, il existe une multitude de bogues "cela ne devrait jamais arriver" se produisant dans la nature. C'est parce que votre algorithme peut ne pas changer, mais ses entrées peuvent changer des années plus tard lorsque personne ne se souvient de ce cas d'utilisation non géré. C'est pourquoi les développeurs expérimentés gèrent ce genre de choses lorsqu'ils sont frais dans leur esprit. Il revient vous mordre plus tard si vous ne le faites pas.
Ce n'est pas une question technique mais une décision de stratégie commerciale. Vous remarquez que la correction suggérée concerne un cas très obscur qui presque ne se produira jamais. Ici, cela fait une grande différence si vous programmez un jouet ou si vous programmez par exemple un équipement médical ou un drone armé. Les conséquences d'un dysfonctionnement rare seront très différentes.
Lorsque vous effectuez des révisions de code, vous devez appliquer une compréhension de base des priorités de l'entreprise au moment de décider combien investir dans la gestion des cas rares. Si vous n'êtes pas d'accord avec votre collègue dans votre interprétation des priorités de l'entreprise, vous voudrez peut-être avoir une discussion avec quelqu'un du côté des affaires.
Les révisions de code ne concernent pas uniquement l'exactitude du code. En réalité, c'est assez loin dans la liste des avantages, derrière le partage des connaissances et un processus lent mais régulier vers la création d'un consensus de style/conception d'équipe.
Au fur et à mesure que vous vivez, ce qui compte comme "correct" est souvent discutable, et chacun a son propre point de vue sur ce que c'est. D'après mon expérience, un temps et une attention limités peuvent également rendre les revues de code très incohérentes - le même problème peut être détecté ou non en fonction de différents développeurs et à des moments différents par le même développeur. Les examinateurs dans l'esprit de "qu'est-ce qui améliorerait ce code?" suggéreront souvent des changements qu’ils n’ajouteraient pas naturellement à leurs propres efforts.
En tant que codeur expérimenté (plus de 15 ans en tant que développeur), je suis souvent évalué par des codeurs ayant moins d'années d'expérience que moi. Parfois, ils me demandent des changements avec lesquels je suis légèrement en désaccord ou que je pense sans importance. Cependant, je fais toujours ces changements. Je ne me bats pour des changements que lorsque je pense que le résultat final entraînerait une faiblesse du produit, où le coût en temps est très élevé, ou lorsqu'un point de vue "correct" peut être rendu objectif (par exemple, le changement demandé est gagné " t travailler dans la langue que nous utilisons, ou un benchmark montre qu'une amélioration des performances déclarée n'en est pas une).
Je suggère donc de bien choisir vos batailles. Deux jours de codage d'un cas de test que vous pensez non nécessaire ne valent probablement pas le temps/l'effort à combattre. Si vous utilisez un outil de révision, tel que les demandes d'extraction GitHub, alors peut-être y commenter les coûts/avantages que vous percevez, afin de noter votre objection, mais acceptez de continuer à faire le travail. Cela compte comme un léger recul, de sorte que le réviseur sait qu'il atteint une limite et, plus important encore, inclut votre justification afin que des cas comme celui-ci puissent être escaladés s'ils tombent dans une impasse. Vous voulez éviter l'escalade des désaccords écrits - vous ne voulez pas avoir un argument de style forum Internet sur les différences de travail - il peut donc être utile d'aborder le problème et d'enregistrer un résumé juste des résultats de la discussion, même si vous acceptez toujours de ne pas être d'accord sur la nécessité du travail (il est tout à fait possible qu'une courte discussion amicale décidera pour vous deux de toute façon).
Après l'événement, c'est un bon sujet pour les réunions de revue de sprint ou de planification de l'équipe de développement, etc. Présentez-le aussi neutre que possible, par exemple "Lors de l'examen du code, le développeur A a identifié ce cas de test supplémentaire, il a fallu deux jours supplémentaires pour l'écrire. L'équipe pense-t-elle que la couverture supplémentaire était justifiée à ce coût?" - cette approche fonctionne beaucoup mieux si vous effectuez réellement le travail, car elle vous montre sous un jour positif; vous avez fait le travail et souhaitez simplement interroger l'équipe pour l'aversion au risque par rapport au développement de fonctionnalités.
Je vous conseille au moins d'affirmer contre l'affaire obscure. De cette façon, non seulement les futurs développeurs voient que vous avez activement décidé contre le cas, mais avec une bonne gestion des échecs, qui devrait déjà être en place, cela surprendrait également.
Et puis, faites un cas de test qui affirme cet échec. De cette façon, le comportement est mieux documenté et apparaîtra dans les tests unitaires.
Cette réponse suppose évidemment que votre jugement sur le fait même d'être "extrêmement improbable, voire possible" est correct et nous ne pouvons pas en juger. Mais si c'est le cas, et votre collègue est d'accord, une affirmation explicite contre l'événement devrait être une solution satisfaisante pour vous deux.
Puisque vous semblez être nouveau là-bas, il n'y a qu'une seule chose que vous pouvez faire - vérifiez avec le chef d'équipe (ou chef de projet). 13 heures est une décision commerciale; pour certaines entreprises/équipes, beaucoup; pour certains, rien. Ce n'est pas votre décision, pas encore.
Si le responsable dit "couvrir ce cas", très bien; s'il dit "non, vissez", très bien - sa décision, sa responsabilité.
Quant aux revues de code en général, détendez-vous. Le fait de vous renvoyer une tâche une ou deux fois est parfaitement normal.
Une chose que je ne pense pas avoir abordée en nature, bien qu'elle ait été évoquée dans la réponse de @SteveBarnes:
Quelles sont les répercussions d'un échec?
Dans certains domaines, un échec est une erreur sur une page Web. Un écran bleu PC et redémarre.
Dans d'autres domaines, c'est la vie ou la mort - une voiture autonome se verrouille. Le stimulateur médical cesse de fonctionner. Ou dans la réponse de Steve: des choses explosent entraînant la perte de millions de dollars.
Il y a un monde de différence dans ces extrêmes.
Que ce soit ou non 13 heures pour couvrir un "échec" vaut finalement ne devrait pas être à vous. Cela devrait appartenir à la direction et aux propriétaires. Ils devraient avoir une idée d'ensemble.
Vous devriez être en mesure de deviner ce qui en vaudra la peine. Votre robot va-t-il simplement ralentir ou s'arrêter? Des performances dégradées? Ou une panne du robot entraînera-t-elle des dommages monétaires? La perte de la vie?
La réponse à CETTE question devrait conduire la réponse à "vaut-il 13 heures de temps de l'entreprise". Remarque: j'ai dit l'heure des sociétés. Ils paient les factures et décident finalement de ce qui en vaut la peine. Votre direction devrait avoir le dernier mot dans les deux cas.
Peut-être parler à la personne qui est chargée de prioriser le travail? Au démarrage, il peut s'agir d'un CTO ou d'un propriétaire de produit. Il pourrait aider à déterminer si ce travail supplémentaire est nécessaire et pourquoi. Vous pouvez également apporter vos inquiétudes lors de standups quotidiens (si vous en avez).
S'il n'y a pas de responsabilité claire (par exemple, le propriétaire du produit) pour les travaux de planification, essayez de parler aux gens autour de vous. Plus tard, cela pourrait devenir un problème que tout le monde pousse le produit dans une direction opposée.
La meilleure façon de gérer les désaccords est la même, que vous soyez un développeur junior ou senior, ou même un PDG.
Si vous n'avez jamais regardé Columbo, c'était un spectacle assez fantastique. Columbo était ce personnage très modeste - la plupart des gens pensaient qu'il était un peu fou et ne valait pas la peine de s'inquiéter. Mais en apparaissant humble, et en demandant simplement aux gens d'expliquer qu'il a réussi à obtenir son homme.
Je pense que c'est aussi lié à la méthode socratique .
En général, vous voulez vous poser des questions à vous-même et aux autres pour vous assurer que vous faites les bons choix. Pas à partir d'une position de "j'ai raison, vous avez tort", mais à partir d'une position de découverte honnête. Ou du moins du mieux que vous pouvez.
Dans votre cas, vous avez ici deux idées, mais elles ont fondamentalement le même objectif: améliorer le code.
Vous avez l'impression que lésiner sur la couverture du code pour un cas potentiellement improbable (impossible?) En faveur du développement d'autres fonctionnalités est la meilleure façon de le faire.
Votre collègue a l'impression qu'il vaut mieux être plus prudent avec les caisses d'angle.
Que voient-ils que vous ne voyez pas? Que voyez-vous qu'ils ne voient pas? En tant que développeur junior, vous êtes en fait dans une excellente position car vous naturellement devriez poser des questions. Dans une autre réponse, quelqu'un mentionne la probabilité surprenante d'un cas d'angle. Vous pouvez donc commencer par: "Aidez-moi à comprendre - j'avais l'impression que X, Y et Z - qu'est-ce qui me manque? Pourquoi le widget frambouillerait-il? J'avais l'impression qu'il fintublerait dans des circonstances cromulentes. Will le bâton swizzle embiggen réellement les brosses ANZA? "
Lorsque vous remettez en question vos hypothèses et vos conclusions, vous creuserez, découvrirez des biais et finirez par déterminer quelle est la bonne marche à suivre.
Commencez avec l'hypothèse que tout le monde dans votre équipe est parfaitement rationnel et qu'ils ont le meilleur intérêt de l'équipe et du produit à l'esprit, tout comme vous. S'ils font quelque chose qui n'a pas de sens, alors vous devez comprendre ce que vous ne savez pas qu'ils font ou ce que vous savez qu'ils ne le font pas.
13 heures, ce n'est pas si grave, je le ferais. N'oubliez pas que vous êtes payé pour cela. Il s'agit simplement de "sécurité d'emploi". Il est également préférable de conserver un bon karma au sein de l'équipe. Maintenant, si c'était quelque chose qui vous prendrait une semaine ou plus, alors vous pourriez impliquer votre manager et lui demander si c'est la meilleure utilisation de votre temps, surtout si vous n'êtes pas d'accord avec cela.
Cependant, vous semblez avoir besoin d'un effet de levier dans votre groupe. Voici comment vous obtenez un effet de levier: demandez pardon, ne demandez pas la permission. Ajoutez des éléments au programme comme bon vous semble (dans le cadre du cours, c'est-à-dire assurez-vous qu'il résout complètement le problème que le patron veut ..), et informez le manager ou vos collègues après coup. Ne leur demandez pas: "Est-ce correct si j'ajoute la fonction X". Au lieu de cela, ajoutez simplement les fonctionnalités que vous souhaitez personnellement dans le programme. S'ils sont contrariés par une nouvelle fonctionnalité ou ne sont pas d'accord, soyez d'accord pour la supprimer. S'ils l'aiment, gardez-le.
De plus, chaque fois qu'ils vous demandent de faire quelque chose, faites un effort supplémentaire et ajoutez beaucoup de choses qu'ils ont oublié de mentionner ou de choses qui fonctionneraient mieux que ce qu'ils ont dit. Mais ne leur demandez pas si c'est "ok" d'aller plus loin. Il suffit de le faire et de leur en parler avec désinvolture une fois terminé. Ce que vous faites, c'est de les former ..
Ce qui se passera, c'est que votre manager vous considérera comme un "fonceur" et commencera à vous faire confiance, et vos collègues commenceront à vous voir comme le chef de file avant que vous commenciez à posséder le programme. Et puis, lorsque des choses comme ce que vous mentionnez se produiront à l'avenir, vous aurez plus à dire, car vous êtes essentiellement la star de l'équipe et ses coéquipiers reculeront si vous n'êtes pas d'accord avec eux.
Le code peut TOUJOURS être meilleur.
Si vous êtes dans une révision de code et que vous ne voyez rien de mieux ou un test unitaire qui pourrait détecter un bogue, ce n'est pas le code qui est parfait, mais le réviseur qui ne fait pas son travail. Que vous choisissiez de mentionner l'amélioration est un choix personnel. Mais presque chaque fois que votre équipe procède à une révision du code, il devrait y avoir des choses que quelqu'un remarque qui pourraient être meilleures ou tout le monde vient probablement de perdre son temps.
Cela dit, que vous agissiez sur les commentaires ou non, cela dépend de votre équipe. Si vos modifications corrigent le problème ou ajoutent suffisamment de valeur sans changement pour que votre équipe les accepte, fusionnez-les et enregistrez leurs commentaires dans le backlog pour que quelqu'un les traite plus tard. Si l'équipe trouve que vos modifications ajoutent plus de risques ou de complexité que de valeur, vous devez résoudre les problèmes en conséquence.
N'oubliez pas que le code any a au moins un autre cas Edge qui pourrait être testé et pourrait utiliser au moins un refactoring supplémentaire. C'est pourquoi les révisions de code sont mieux faites en groupe avec tout le monde regardant le même code en même temps. Pour qu'à la fin, tout le monde puisse parvenir à un consensus sur la question de savoir si le code examiné est acceptable (tel quel) et ajoute suffisamment de valeur pour fusionner dans la base communautaire ou si certaines choses doivent être faites avant qu'il y ait suffisamment de valeur pour fusionner .
Étant donné que vous posez cette question, je suppose que vous ne faites pas réellement de "révisions de code", mais que vous créez plutôt une demande d'extraction ou un autre mécanisme de soumission pour que d'autres commentent de manière non déterministe. Alors maintenant, vous êtes dans un problème de gestion et une définition de fait. Je suppose que votre gestion est indécise et ne comprend pas réellement le processus et le but des revues de code et n'a probablement pas de "définition de fait" (DOD). Parce que s'ils le faisaient, votre DOD répondrait explicitement à cette question et vous n'auriez pas à venir ici et à le demander.
Comment le corrigez-vous? Eh bien, demandez à votre responsable de vous donner un DOD et de vous dire si vous devez toujours mettre en œuvre tous les commentaires. Si la personne en question est votre manager, la réponse va de soi.
La révision du code a plusieurs objectifs. Celui que vous connaissez évidemment est: " Ce code est-il adapté à l'usage?" En d'autres termes, est-il fonctionnellement correct; est-il correctement testé; les parties non évidentes sont-elles correctement commentées; est-il conforme aux conventions du projet?
Une autre partie de l'examen du code est le partage des connaissances sur le système. C'est l'occasion à la fois pour l'auteur et pour le réviseur de se renseigner sur le code modifié et sur la façon dont il interagit avec le reste du système.
Un troisième aspect est qu'il peut fournir un examen des problèmes qui existaient avant d'apporter des modifications. Très souvent, lorsque je passe en revue les modifications de quelqu'un d'autre, je repère quelque chose que j'ai manqué lors d'une précédente itération (assez souvent quelque chose de moi-même). Une déclaration comme: "Voici une occasion de rendre cela plus robuste qu'il ne l'était", n'est pas une critique, et ne le prenez pas comme tel!
Mon équipe actuelle considère la révision du code non seulement comme une passerelle ou un obstacle que le code doit passer indemne avant la validation, mais surtout comme une opportunité pour une discussion quelque peu structurée d'un domaine particulier de fonctionnalité. C'est l'une des occasions les plus productives de partage d'informations. (Et c'est une bonne raison de partager la révision autour de l'équipe, plutôt que toujours la même critique).
Si vous percevez les revues de code comme une activité de confrontation, c'est une prophétie auto-réalisatrice. Si au contraire vous les considérez comme la partie la plus collaborative de votre travail, ils stimuleront des améliorations continues de votre produit et de la façon dont vous travaillez ensemble. Cela peut aider si un avis peut être clair sur les priorités relatives de ses suggestions - il y a un mille de différence entre "J'aimerais un commentaire utile ici" et "Cela casse si x est jamais négatif", par exemple .
Après avoir fait beaucoup de déclarations générales ci-dessus, comment cela s'applique-t-il à votre situation spécifique? J'espère qu'il est maintenant évident que mon conseil est de répondre à l'examen par des questions ouvertes et de négocier quelle approche a le plus de valeur. Pour votre exemple de cas où un test supplémentaire est suggéré, alors quelque chose comme: "Oui, nous pouvons le tester; j'estime que cela prendra <time> à mettre en œuvre. Pensez-vous que l'avantage est Et y a-t-il autre chose que nous pouvons faire pour garantir que le test n'est pas nécessaire? "
Une chose qui me frappe quand je lis votre question: si cela prend deux jours d'efforts pour écrire un nouveau cas de test, alors soit votre nouveau test est un scénario très différent de vos tests existants (auquel cas il a probablement beaucoup de ou vous avez identifié un besoin de réutilisation améliorée du code dans la suite de tests.
Enfin, comme un commentaire général sur la valeur des revues de code (et comme un résumé concis de ce que j'ai dit ci-dessus), j'aime cette déclaration, en Les mainteneurs ne se mettent pas à l'échelle = par Daniel Vetter :
Au moins pour moi, la révision ne consiste pas seulement à garantir une bonne qualité de code, mais aussi à diffuser les connaissances et à améliorer la compréhension. Au début, il y a peut-être une personne, l'auteur (et ce n'est pas une donnée), qui comprend le code. Après un bon examen, il devrait y avoir au moins deux personnes qui le comprennent parfaitement, y compris les cas d'angle.
Cette question ne concerne pas les vertus de la programmation défensive, les dangers des cas d'angle ou les risques catastrophiques de bugs dans les produits physiques. En fait, c'est pas même vraiment du génie logiciel.
Il s'agit vraiment de savoir comment un praticien débutant gère une instruction d'un praticien senior lorsque le jeune praticien ne peut pas être d'accord ou l'apprécier.
Il y a deux choses que vous devez apprécier pour être développeur junior. Premièrement, cela signifie que, même si c'est possible que vous avez raison et que vous avez tort, c'est - selon la prépondérance des probabilités - peu probable. Si votre collègue fait une suggestion dont vous ne pouvez pas voir la valeur, vous devez sérieusement envisager la possibilité que vous n'ayez tout simplement pas assez d'expérience pour le comprendre. Je ne comprends pas ce sens de ce post.
La deuxième chose à apprécier est que votre partenaire senior est soi-disant parce qu'il a plus de responsabilités. Si un junior rompt quelque chose d'important, il n'aura pas de problèmes s'il a suivi les instructions. Si une personne âgée autorisé à les casser, cependant - en ne soulevant pas de problèmes lors de la révision du code, par exemple - ils seraient à juste titre très embêtés.
En fin de compte, c'est une exigence implicite de votre travail que vous observiez les instructions de ceux qui font confiance à l'entreprise pour mener leurs projets. Êtes-vous généralement incapable de vous en remettre aux aînés lorsqu'il y a de bonnes raisons de valoriser leur expérience? Avez-vous l'intention de ne suivre aucune instruction que vous ne pouvez pas comprendre? Pensez-vous que le monde devrait s'arrêter jusqu'à ce que vous soyez convaincu? Ces valeurs sont incompatibles avec le travail en équipe.
Un dernier point. Pensez aux projets que vous avez écrits il y a six mois. Pensez aux projets que vous avez écrits à l'université. Voyez à quel point ils semblent mauvais - tous les bugs et la conception à l'envers, les angles morts et les abstractions malavisées? Et si je vous disais que dans six mois, vous compterez les mêmes défauts dans le travail que vous faites aujourd'hui? Cela vous aide-t-il à démontrer le nombre d'angle mort dans votre approche actuelle? Parce que c'est la différence que fait l'expérience.
fait constamment des commentaires sur mon code qui me suggèrent de faire beaucoup plus de travail que nécessaire.
Vous pouvez faire des recommandations, mais en fin de compte ce n'est pas votre rôle de décider de ce qui est nécessaire. C'est votre travail de mettre en œuvre ce que la gestion ou (dans ce cas votre réviseur) décide est nécessaire. Si vous êtes en désaccord avec ce qui est nécessaire trop ou trop fortement, vous vous retrouverez probablement sans emploi. Par conséquent, cela fait partie de votre professionnalisme de vous en sortir et d'être en paix avec cela.
Il avait suggéré que je traite un cas obscur qui est extrêmement peu probable
Il y a d'autres bonnes réponses ici qui montrent comment même les non-bugs (c'est-à-dire quelque chose qui ne peut pas échouer jamais) devraient encore être retravaillés parfois. (par exemple, dans le cas de la construction de la sécurité future du produit, des normes suivantes, etc.) Une partie du rôle d'un grand développeur est d'avoir autant de confiance que possible que votre code sera robuste dans chaque situation imaginable à chaque fois, et futur -protégé aussi, pas seulement travailler dans des situations testées dans les conditions actuelles la plupart du temps
Suggestions aux réviseurs de code pour augmenter l'utilité commerciale de votre révision de code (vous, OP, devriez proposer un tel changement):
Marquez vos commentaires par type. "Critique"/"Incontournable"/"Facultatif"/"Améliorations suggérées"/"Ravi d'avoir"/"Je réfléchis".
Si cela semble trop CDO/anal/compliqué, utilisez au moins 2 niveaux: "Doit corriger pour passer la revue et être autorisé à fusionner votre changement"/"Tous les autres".
Suggestions pour gérer les suggestions de révision de code qui semblent moins critiques à faire:
Créez un ticket ouvert dans votre système de billetterie de choix (votre équipe en utilise un, espérons-le?), En suivant la suggestion
Mettez le ticket # en tant que commentaire de réponse à l'élément de révision du code si votre processus autorise les réponses aux commentaires comme Fisheye ou les critiques par e-mail.
Contactez le réviseur et demandez explicitement si cet élément est du type "doit être corrigé ou ne sera pas fusionné/publié".
- Si la réponse est "Oui", mais que vous n'êtes pas d'accord, laissez la personne responsable de la gestion du projet (PM, votre responsable, etc ...) prendre une décision - présentez le désaccord de manière complète et honnête. Il ne s'agit pas de savoir qui d'entre vous a "raison" mais de savoir ce qui est le mieux pour le projet, donc le travail de PM/manager.
Maintenant, traitez ce ticket comme toute autre demande de développement.
S'il est décidé d'être urgent après l'escalade, traitez-le comme une demande de développement urgente. Dépriorisez les autres travaux et travaillez dessus.
Sinon, travaillez dessus en fonction de la priorité qui lui a été attribuée et de son retour sur investissement (qui peut différer en fonction de votre métier comme expliqué dans les autres réponses).
Vous devriez pas escalader ceci à la direction.
Dans la plupart des entreprises, le responsable de la gestion choisira toujours de ne pas écrire ce test supplémentaire, de ne pas perdre de temps à améliorer légèrement la qualité du code, de ne pas perdre du temps refactoring.
Dans de nombreux cas, la qualité du code dépend des règles non écrites de l'équipe de développement et des efforts supplémentaires déployés par les programmeurs.
Vous êtes développeur junior et ceci est votre premier examen de code. Vous devez accepter les conseils et faire le travail. Vous ne pouvez améliorer le flux de travail et les règles de votre équipe que si vous les connaissez et les respectez pendant un certain temps afin de comprendre pourquoi ils sont là. Sinon, vous serez ce nouveau gars qui ne respecte pas les règles et devient le loup solitaire de l'équipe.
Vous êtes nouveau dans l'équipe, suivez les conseils que vous recevez pendant un certain temps, découvrez pourquoi ils sont là, n'apportez pas les premiers conseils que vous mettez en question lors de la réunion de mêlée. Les vraies priorités commerciales vous seront évidentes après un certain temps sans demander (et ce n'est peut-être pas ce que le gestionnaire vous dira face à face).
Il est très important de créer un code qui réponde à votre demande de lead/gestion. Tout autre détail ne serait qu'un "Agréable à avoir". Si vous êtes un expert (lisez ceci: "si vous n'êtes pas un développeur junior") dans votre domaine, alors vous êtes "éligible" pour résoudre les problèmes mineurs que vous rencontrez en cours de route sans consulter à chaque fois vos dirigeants.
Si vous pensez que quelque chose ne va pas et vous êtes relativement expert dans votre domaine, les chances sont élevées, vous avez raison.
Voici quelques déclarations qui pourraient vous être utiles:
- On m'a demandé de faire X, le réviseur de code suggère également de faire Y, dois-je le faire ou dois-je passer à des choses plus importantes?
- Vous me proposez Y, alors pouvez-vous trouver au moins un cas de test qui pourrait détecter ce comportement afin que je puisse le tester? Je crois que ce code ne sera pas appelé.
- Peut-être ne devrions-nous pas d'abord développer une solution de secours sûre pour les cas non découverts? Nous les attrapons donc tôt et nous nous mettons en route pour nous concentrer sur des choses plus importantes.
- OK, pendant que j'implémente Y, pourriez-vous être si gentil d'écrire quelques cas de test pour que nous accomplissions cette chose ne fois pour toutes?
- On m'a demandé de faire X, et je pense que je pourrais faire Y à moins qu'il n'y ait d'autres priorités. La prochaine fois, pourquoi ne déposez-vous pas une demande de fonctionnalité au lieu de la mettre en commentaire sur mon code? Au moins, nous pouvons entendre d'autres opinions des autres membres de l'équipe sur cette fonctionnalité avant de la mettre en œuvre (généralement tout élément important devrait être une fonctionnalité et devrait être géré par plusieurs personnes; généralement, la révision du code devrait consister à réviser approches de code et de solutions; le reste est la correction de bogues et les fonctionnalités).
Pensez-vous sérieusement que l'attitude de votre critique est endommageant le projet ou pensez-vous qu'il est juste la plupart du temps (sauf peut-être parfois qu'il fait juste des erreurs mineures dans l'évaluation et exagère )?
Pour moi, cela ressemble plus à de l'écriture de choses qui n'appartiennent pas à une révision de code, ce qui est une mauvaise pratique car cela rend plus difficile pour tout le monde de suivre les choses. Cependant, je ne sais pas quels autres commentaires de révision il a faits, donc je ne peux rien dire sur d'autres cas.
En général, essayez d'éviter les deux problèmes suivants:
- Vous ne faites pas ce qui a été demandé
- Vous faites que votre critique se sente stupide
S'il examine réellement votre code, c'est parce que la direction lui fait plus confiance que vous.