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

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.

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.

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 .

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.

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.

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.

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.

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).