Je travaille dans une startup de la robotique dans une équipe de couverture de chemin et après avoir soumis une demande d'extraction, mon code est examiné.
Mon coéquipier, qui fait partie de l'équipe depuis plus d'un an, a fait quelques remarques dans mon code qui suggèrent que je fasse beaucoup plus de travail que je ne le crois nécessaire. Non, je ne suis pas un développeur paresseux. J'aime le code élégant qui contient de bons commentaires, des noms de variable, une indentation et gère correctement les cas. Cependant, il a en tête un autre type d'organisation avec lequel je ne suis pas d'accord.
Je vais donner un exemple:
J'avais passé une journée à écrire des scénarios de test pour modifier un algorithme de recherche de transition que j'avais créé. Il m'avait suggéré de traiter un cas obscur qui aurait très peu de chances de se produire - en fait, je ne suis pas sûr que cela soit possible. Le code que j'ai créé fonctionne déjà dans tous nos scénarios de test d'origine et dans certains nouveaux que j'ai trouvés. Le code que j'ai créé passe déjà plus de 300 simulations exécutées tous les soirs. Cependant, gérer ce cas obscur me prendrait 13 heures qui pourraient être mieux dépensées à essayer d’améliorer les performances du robot. Pour être clair, l’algorithme précédent que nous utilisions jusqu’à présent ne traitait pas non plus ce cas obscur, et pas une seule fois, dans les 40 000 rapports générés. Nous sommes une start-up et devons développer le produit.
Je n'ai jamais eu de révision de code auparavant et je ne suis pas sûr de trop argumenter; devrais-je me taire et faire ce qu'il dit? J'ai décidé de garder la tête basse et de faire le changement même si je suis tout à fait en désaccord sur le fait que c'était une bonne utilisation du temps.
Je respecte mon collègue et je le reconnais comme un programmeur intelligent. Je ne suis tout simplement pas d'accord avec lui sur un point et je ne sais pas comment gérer un désaccord dans une révision du code.
Je pense que la réponse que j'ai choisie répond à ce critère, qui consiste à expliquer comment un développeur débutant peut gérer un désaccord lors d'une révision de code.