Comment assumer la responsabilité de mon code lorsqu'un collègue apporte des améliorations inutiles sans préavis?

71

Un de mes coéquipiers est un homme à tout faire dans notre magasin d’informatique et je respecte ses idées.

Cependant, parfois, il revoit mon code (il est le commandant en second de notre chef d’équipe, alors c’est prévu) sans avertissement. Alors, parfois, il passe en revue mes modifications avant qu'elles n'atteignent l'objectif final et apporte des modifications immédiatement ... et a même interrompu mon travail une fois.

D'autres fois, il a apporté des améliorations inutiles à certains de mes codes datant de plus de 3 mois.

Cela m'agace pour plusieurs raisons:

  1. Je n'ai pas toujours une chance de réparer mes erreurs
  2. Il n'a pas pris le temps de me demander ce que j'essayais d'accomplir lorsqu'il est confus, ce qui pourrait affecter ses tests ou ses modifications.
  3. Je ne pense pas toujours que son code est lisible
  4. Les délais ne sont pas un problème et sa charge de travail actuelle n'exige aucun travail dans mes projets autre que la révision de mes modifications de code.

En tout cas, je lui ai dit dans le passé de bien vouloir me tenir au courant s’il voyait quelque chose dans son travail qu’il voulait changer pour que je puisse prendre possession de mon code (peut-être aurais-je dû dire «lacunes») et qu’il n’ait pas réagi .

Je crains d’être agressif lorsque je lui demande de m’expliquer ses changements.

C'est juste une personne silencieuse qui reste isolée, mais ses actions continuent. Je ne veux pas le bannir de modifications de code (pas comme je pourrais le faire), car nous sommes une équipe - mais je veux faire ma part pour aider notre équipe.

Clarifications ajoutées:

  • Nous partageons 1 branche de développement. Je n'attends pas que toutes mes modifications soient terminées, car je risque de perdre un travail important. Je veille donc à ce que mes modifications se construisent et ne cassent rien.
  • Ce qui me préoccupe, c'est que mon coéquipier n'explique pas la raison ou le but de ses changements. Je ne pense pas qu'il devrait avoir besoin de ma bénédiction, mais si nous ne sommes pas d'accord sur une approche, je pense qu'il serait préférable de discuter du pour et du contre et de prendre une décision une fois que nous comprenons tous les deux ce qui se passe.
  • Je n’en ai pas encore discuté avec notre chef d’équipe car je préférerais résoudre les désaccords personnels sans impliquer la direction, à moins que cela ne soit nécessaire. Puisque mon inquiétude semblait être plus une affaire personnelle qu'une menace pour notre travail, j'ai choisi de ne pas déranger le chef d'équipe. Je travaille sur des idées de processus de révision de code - pour aider à promouvoir les avantages de révisions de code plus organisées sans parler entièrement de mes marottes.
Jesslyn
la source
20
Utilisez-vous git, CVS ou TFS pour votre dépôt de code? Il suffit d'annuler ses commits. Il finira par l'obtenir :)
6
Dans mon organisation, tous les changements de code sont supposés passer par une révision, et il est considéré comme une mauvaise forme pour enregistrer une modification sans noter dans la description de la liste des modifications qui a été le relecteur. L'introduction de ce principe dans votre organisation pourrait constituer une solution à long terme au problème de la vérification par vos collègues des modifications apportées au code que vous avez écrit sans vérification.
Carolyn
13
Pourquoi avez-vous des modifications non terminées dans une branche partagée? C'est une mauvaise idée, et pas seulement pour la raison que vous avez rencontrée.
Hyde
15
Bien sûr, cela dépend du VCS que vous utilisez, mais cela pourrait être une chose à considérer, à commencer à utiliser davantage de branches. Avec la branche personnelle, l’OMI est génial lorsque vous pouvez commettre (et pousser avec DVCS) quand vous le souhaitez sans vous inquiéter, et ne fusionner que lorsque vous avez terminé avec une pièce, ou ne fusionner que partiellement si nécessaire (un bon DVCS facilite cela). Cela fonctionne également très bien avec la révision de code, étant capable de le faire naturellement et de résoudre les problèmes avant la fusion.
Hyde
4
@ Jesslyn - Votre chef d'équipe est-il préoccupé par le fait que votre coéquipier passe du temps à apporter des améliorations inutiles à l'ancien code? À tout le moins, il semble inefficace pour votre coéquipier de consacrer du temps à apporter des modifications inutiles, par opposition à des tâches plus prioritaires. En outre, si votre coéquipier préfère passer du temps à "réparer" votre code plutôt que de vous permettre de le faire vous-même, cela semble tout aussi inefficace. Avez-vous discuté de ces problèmes avec le responsable de votre équipe?
Falaise

Réponses:

81

Je pense que la plupart des développeurs se retrouvent dans cette position à un moment donné, et j'espère que chaque développeur qui s'est senti victime de victimisation réalise à quel point il sera frustrant de devenir senior et se sent obligé de nettoyer le code écrit par les juniors.

Pour moi, éviter les conflits dans cette situation se résume à deux choses:

  1. Avec l' aimable autorisation . En parler à quelqu'un de son code permet à un développeur de savoir que vous êtes intéressé et que vous pouvez en discuter en tant que professionnel adulte.

  2. Oubliez la "propriété de code" - l'équipe est propriétaire du code . Les autres personnes qui souhaitent apporter ces changements sont une bonne chose. Si un développeur senior apporte des modifications "illisibles" ou pires, annulez-les. Vous n'avez pas besoin d'être agressif, il suffit de faire savoir à un éditeur que ses modifications n'ont pas fonctionné et vous êtes plus qu'heureux de discuter de votre revirement.

N'oubliez pas que la propriété du code par une équipe est excellente et qu'elle va dans les deux sens. Si vous voyez quelque chose qui n'a pas de sens dans le code de quelqu'un d'autre, corrigez-le. Être trop possessif et insuffisamment communicatif est un moyen infaillible de créer un environnement de développement toxique.

Michael
la source
4
Je pense que cela revient au point 1 - avoir une discussion avec lui. Compter sur le fait que les modifications de code par rapport au développeur d'origine est une gestion épouvantable (je ne dis pas que cela ne se produit pas) et je dirais que vous devez demander de meilleurs métriques. Traversez ce pont si et quand cela arrive.
Michael
2
Je pense que c'est sur quoi nous devrions tous nous concentrer - en général, vos coéquipiers ne veulent pas vous faire mal paraître - ne perdez pas de temps à analyser, mais devenez meilleur et un membre plus précieux de l'équipe (je sais que c'est plus facile que fait cependant!)
Michael
7
@ Jesslyn, s'il vous le fait, il le fera probablement à tout le monde. Je doute que quelqu'un compte cela contre vous. (S'il ne le fait pas à tout le monde, vous pourriez avoir un problème différent)
user606723
3
@tgkprog: (1) Bien sûr, il est très important de recueillir les réactions des autres et j'ai appris quelques choses en consultant le code des autres, mais (2) si vous voulez apprendre les uns des autres, vous devez suggérer un changement et en discuter ensemble. . Changer simplement des choses aléatoires parce que vous pensez que le code est meilleur après le changement n'est pas la bonne approche. Il existe de meilleures approches telles que la révision de code à l'aide d'outils de révision.
Giorgio
2
oui, je pensais à des fois où j'avais corrigé le code des autres avant une échéance à 23h mais quand même
j'envoyais
86

Vous et la plupart des répondeurs abordez cette question comme un problème de communication entre deux collègues, mais je ne le pense pas vraiment. Ce que vous décrivez ressemble plus à un processus de révision de code horriblement brisé qu’autre chose.

Tout d'abord, vous mentionnez que votre collègue est le commandant en second et qu'il s'attend à ce qu'il revoit votre code. C'est juste faux. Par définition, les revues de code par les pairs ne sont pas hiérarchiques et ne consistent pas uniquement en la recherche de défauts. Ils peuvent également fournir des expériences d'apprentissage (pour toutes les personnes concernées), une opportunité d'interaction sociale et s'avérer un outil précieux pour la création d'une propriété collective de code. Vous devriez également revoir son code de temps en temps, apprendre de lui et le corriger quand il se trompe (personne ne le comprend bien à chaque fois).

De plus, vous mentionnez que votre collègue apporte des modifications immédiatement. C'est également faux, mais bien sûr vous le savez déjà; vous n'auriez pas posé cette question si son approche de gung ho n'était pas un problème. Cependant, je pense que vous cherchez une solution au mauvais endroit. Pour être tout à fait honnête, votre collègue me rappelle un peu ... de moi, et ce qui a fonctionné pour moi dans des situations similaires était un processus d’examen bien défini et solide et un ensemble d’instruments géniaux. Vous ne voulez pas vraiment empêcher votre collègue de réviser votre code et de lui demander de s'arrêter et de vous parler avant que chaque petit changement ne fonctionne réellement. Cela pourrait peut-être, pendant un moment, mais il atteindra bientôt un point où cela deviendra trop gênant et vous serez de retour à votre point de départ, ou pire: il arrêtera simplement de réviser votre code.

Un outil de révision de code par les pairs pourrait constituer une solution. J'évite généralement les recommandations de produits, mais pour les critiques de code, Atlassian's Crucibleest vraiment un épargnant de vie. Ce que cela fait peut paraître très simple, et ça l'est, mais cela ne veut pas dire que ce n'est pas incroyablement génial. Il se connecte à votre référentiel et vous permet de passer en revue des ensembles de modifications, des fichiers ou des groupes de fichiers individuels. Vous ne pouvez modifier aucun code, mais vous commentez tout ce qui ne vous semble pas juste. Et si vous devez absolument changer le code de quelqu'un d'autre, vous pouvez simplement laisser un commentaire avec l'ensemble de modifications expliquant vos modifications. La vidéo d’introduction sur la page produit de Crucible vaut la peine d’être visionnée si vous souhaitez plus de détails. Les prix de Crucible ne sont pas pour tout le monde, mais il existe de nombreux outils d'évaluation par les pairs disponibles gratuitement. Review Board est un outil avec lequel j'ai apprécié et apprécié, et je suis sûr que vous en trouverez beaucoup d'autres avec une simple recherche Google.

Quel que soit l'outil que vous choisissiez, cela changera complètement votre processus. Inutile de vous arrêter, de vous lever de votre chaise, d’interrompre l’autre personne et de discuter des modifications; tout ce que vous avez à faire est de prendre du temps chaque semaine et de passer en revue les commentaires (une fois par semaine n’est qu’une suggestion. Vous connaissez votre emploi du temps et votre routine quotidienne mieux que moi). Plus important encore, les révisions principales sont stockées dans une base de données quelque part et vous pouvez les récupérer à tout moment. Ce ne sont pas des discussions éphémères autour de la fontaine à eau. Mon cas d'utilisation préféré pour les anciennes critiques est l'introduction d'un nouveau membre de l'équipe dans notre base de code. Il est toujours agréable de pouvoir guider une nouvelle personne dans la base de code en indiquant exactement où nous étions bloqués, en cas d'opinions divergentes, etc.

Vous mentionnez ensuite que vous ne trouvez pas toujours le code de ce collègue lisible. Cela me permet de savoir que vous n'avez pas un ensemble commun de normes de codage, et c'est une mauvaise chose. Encore une fois, vous pouvez aborder ceci comme un problème de personnes ou comme un problème de processus, et encore une fois, je suggérerais fortement ce dernier. Rassemblez votre équipe et adoptez un style de codage commun et un ensemble de normes dès que possible. Peu importe que vous choisissiez un ensemble de normes communes à votre écosystème de développement ou que vous élaboriez les vôtres. Ce qui compte vraiment, c’est que vos normes soient cohérentes et que vous les respectiez. De nombreux outils peuvent vous aider, mais la discussion est tout à fait différente. Juste pour commencer, une chose très simple à faire est d’avoir un hook de pré-commit qui exécute une sorte de formateur de style sur votre code. Vous pouvez continuer à écrire votre code comme bon vous semble et laisser l'outil "le réparer" automatiquement avant que quelqu'un d'autre ne le voie.

Enfin, vous avez mentionné dans un commentaire que la direction ne pensait pas que des agences de développement individuelles étaient nécessaires. Eh bien, il y a une raison pour laquelle nous les appelons "branches de développement" et non pas "branches de gestion". Je vais m'arrêter ici car il n'y a aucune raison pour que le coup de gueule qui se forme dans ma tête me quitte.

Cela dit, sachez que je ne doute pas que votre collègue soit (un peu) en faute ici. Ce n'est pas ce que je veux dire, ce que je veux dire, c'est que tout votre processus de développement est également en cause, et c'est quelque chose qui est plus facile à corriger. Munissez-vous des outils appropriés, explorez les nombreux processus formels et informels et choisissez ceux qui conviennent à votre équipe. Bientôt, vous atteindrez un point où vous réaliserez que la plupart de vos "problèmes de personnes" n'existent plus. Et s'il vous plaît, n'écoutez personne (y compris vous-même) qui présente le prétexte "nous sommes une petite équipe, nous n'avons pas besoin de tout cela". Une équipe de développeurs compétents peut configurer les outils nécessaires en moins d'une semaine, automatiser tout ce qui peut être automatisé et ne jamais revenir en arrière.

PS La «propriété de code» est un terme nébuleux, constamment débattu et qui signifie différentes choses pour différentes personnes. Vous pouvez trouver une collection brillante de la plupart des opinions divergentes (et parfois antithétiques) sur C2 .

Yannis
la source
7
+1 et plus si je pouvais. Excellente réponse qui aborde les meilleurs moyens d’améliorer un tel processus.
Waldfee
2
Oui, l'OP a besoin d'un outil de révision du code. Ainsi, vous pouvez réviser le code ensemble. Il ne s'agit pas simplement de quelqu'un qui change de code parce qu'il en a envie. Nous venons tout juste de commencer à utiliser smartbear.com/products/software-development/code-review au travail
Juan Mendes le
19

Qu'est-ce qui fait que vous voulez prendre la responsabilité de "votre code" dans le processus ? Êtes-vous seul responsable du fonctionnement de certaines fonctionnalités? Le responsable a-t-il dit "Michael, je veux que tu prennes la responsabilité de ..."? Ou bien votre responsabilité est-elle implicite, dans la mesure où le responsable et le reste de l'équipe se tournent vers vous chaque fois que certaines fonctionnalités sont endommagées?

De toute façon, si vous avez la responsabilité, vous avez besoin d'une autorité sur le code. La prochaine fois que l'autre personne apportera des modifications unilatérales et que la responsabilité vous reviendra pour la corriger, vous devrez vous asseoir avec elle et demander à ce que votre autorité et vos responsabilités soient harmonisées.

Kevin Cline
la source
5
+1 Pour signaler un fait important: Soit il y a une propriété d'équipe et (1) tous sont responsables (2) tout le monde peut changer le code, soit il y a une propriété individuelle et (1) le propriétaire du module est responsable (2) chaque changement doit être approuvé par le propriétaire du module. Il est fréquent que l’on s’attende à ce qu’un membre de l’équipe soit responsable d’un module, mais un membre plus âgé se sent autorisé à apporter des modifications aléatoires au code. En d'autres termes, il faut éviter la situation de "responsabilité sans autorité".
Giorgio
4

Cela ne résoudra pas tout le problème, mais vous pourrez peut-être ajouter d'autres commentaires à votre code source.

  1. Si le code n'est pas complet, il pourrait être marqué comme tel.
  2. Si le but d'un bloc de code n'est pas auto-documenté, vous devez le documenter.

Essayez de faire de la limonade au lieu de perdre du temps à sucer des citrons. Comme Michael l'a dit, en général, les coéquipiers ne veulent pas vous faire mal paraître. Essayez d'apprendre de vos erreurs et de les appliquer aux révisions futures.

Si vous pensez que ses modifications ont un impact négatif, veuillez le dire (diplomatiquement). Si c'était moi, je demanderais simplement pourquoi des changements spécifiques ont été apportés et voir si vous pouvez défendre vos changements initiaux. Vos collègues de travail sont aussi humains. Il est tout à fait possible qu'il ait oublié quelque chose et / ou ne soit pas conscient de l'impact négatif qu'il produit.

utilisateur606723
la source
3
Garçon qui pourrait devenir déroutant. Imaginez - en ajoutant un commentaire indiquant «Ce code n'est pas complet», puis en oubliant de le supprimer une fois que vous avez terminé le code.
Riwalk
1
@ Stargazer712, Plus déroutant que d'avoir un code incomplet dans la branche?
user606723
C'est à cela que servent les étagères. Ne pas vérifier le code incomplet.
Riwalk
2
Non. Si vous archivez un code incomplet nécessitant un commentaire pour le qualifier de tel, alors vous êtes déjà en enfer. Les commentaires vous emmènent dans un autre coin de l'enfer.
Riwalk
1
Ils s'appellent TODOs, ils sont laissés dans le code de travail tout le temps
Juan Mendes
4

Chacun, implicitement, possède son propre code, quelles que soient la politique, les aspects juridiques ou économiques - c'est la "nature des choses" - vous ressentez naturellement un lien personnel avec votre propre travail.

Si votre collègue adopte le comportement que vous avez décrit et ne réagit pas lorsque vous demandez une alerte, il est discourtois, pour le moins qu'on puisse dire, et tente peut-être de vous nuire (pour dire le pire). .) - ne sonne pas comme un joueur d'équipe.

Un bon collègue baseraient avec vous et signaler le problème avec votre code pour vous - et laissez - vous fixer / modifier ou y répondre adéquatement. Je suis très reconnaissant de ce que même lorsque j'étais un débutant, mes mentors m'avaient toujours montré ce que je faisais mal, expliqué pourquoi et laissé moi (ou m'avaient fait ) le réparer. Cela fait de moi un meilleur programmeur et tout le monde en profite. Et c'est ce que j'ai toujours fait lors de l'examen du travail effectué par d'autres. Ensuite, vous (ou quiconque) apprenez réellement quelque chose de votre "touche-à-tout", et le code et l'équipe s'améliorent tous, y compris votre professeur: L'enseignement aide à la compréhension.

Si possible, je discuterais de la question en privé avec le chef d'équipe. Selon votre description de la situation, un bon chef d'équipe prendra votre parti - un mauvais ne le fera pas ... Évidemment, cela nécessite de la prudence - vous devrez en juger vous-même.

Vecteur
la source
1
À part la déclaration initiale (il y a des équipes qui adoptent la propriété d'équipe et d'autres équipes qui adoptent la propriété individuelle), je trouve les observations dans cette réponse correctes (+1 pour cela): J'ai également observé que la propriété de code partagé était utilisée pour saper une équipe. la position du membre au sein de l'équipe en modifiant arbitrairement son code. Donc, je ne comprends pas les votes négatifs. Ce serait bien si les électeurs du bas voulaient expliquer.
Giorgio
1
Je pense que la réponse de Mikey est une bonne explication sur la façon de rester un joueur d’équipe. Peut-être que c'est trop centré sur les gens? Comme l'a suggéré Yannis, le processus de développement de mon équipe semble être le vrai problème. Quoi qu'il en soit, je suis curieux de savoir pourquoi cela a été voté.
Jesslyn
1
@ Jesslyn - Je suppose que j'ai été voté à cause de ma déclaration "Tout le monde" possède implicitement "son propre code" ". C'est une question philosophique, pas une question de politique. :-)
Vecteur
1
@Mikey: "Tout le monde" possède implicitement "son propre code" "Cela peut faire l'objet d'un débat, bien sûr. Les programmeurs non indépendants signent normalement un contrat stipulant qu'ils ne sont pas propriétaires du code source. En dehors de cela, je pense que l'auteur du code est celui qui comprend le mieux le code, et si quelqu'un d'autre le modifie, alors ni l'auteur ni le second développeur ne comprennent vraiment le code à 100%.
Giorgio
1
@Mikey: La propriété de code partagée essaie de s'assurer que suffisamment de membres de l'équipe comprennent le code assez bien (alors que personne ne le comprend vraiment vraiment). Ceci est préférable à la propriété de code individuel, où chaque module est (au moins en principe) parfaitement compris par un programmeur, mais il y a un risque que cette connaissance soit perdue si ce programmeur quitte.
Giorgio
1

Si vous écrivez du code, alors je devrais le revoir.

Si je modifie votre code lors de l'examen, le code n'est plus le code que j'ai examiné, mais le code que j'ai modifié. Par conséquent, il doit être revu. Probablement par toi.

Si j'engage votre nouveau code avec mes modifications sans que quelqu'un les revoie, alors j'ai commis (1) une modification non examinée et (2) le pire péché possible si les révisions de code sont prises au sérieux.

gnasher729
la source
0

Je pense que vous le gérez comme il le faut pour le moment - mais il y aura bientôt un point critique qui vous distraira au point que vous ne seriez peut-être pas content de coder de cette façon.

Si j'étais vous, je demanderais un entretien personnel rapide avec cette personne et expliquerais mon PDV avec calme et fermeté. La possession en équipe de code, etc., est une bonne chose, mais si vous n'accordez pas à chaque développeur assez d'espace pour mettre son travail en scène, faire des erreurs et améliorer, vous ne construirez jamais de bon code. Cela peut être une zone de friction le plus tôt possible.

(Il existe une réponse totalement différente s'il s'agissait de lieu de travail. Échange de pile. Il est très facile de trouver la bonne façon de procéder à la révision du code. Convaincre votre collègue de s'y conformer est beaucoup plus difficile).

Sandeep
la source