Comment puis-je assumer la responsabilité de mon code lorsque mon collègue apporte des améliorations inutiles sans préavis?
Un de mes coéquipiers est un homme de tous les métiers dans notre boutique informatique et je respecte sa perspicacité.
Cependant, parfois, il passe en revue mon code (il est le commandant en second de notre chef d'équipe, donc c'est prévu) sans prévenir. Donc, 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:
- Je n'ai pas toujours la possibilité de corriger mes erreurs
- Il n'a pas pris le temps de me demander ce que j'essayais d'accomplir quand il est confus, ce qui pourrait affecter ses tests ou ses changements
- Je ne pense pas toujours que son code soit lisible
- Les délais ne sont pas un problème et sa charge de travail actuelle ne nécessite aucun travail dans mes projets autres que l'examen de mes modifications de code.
Quoi qu'il en soit, je lui ai dit par le passé de me tenir au courant s'il voit quelque chose dans mon travail qu'il veut changer pour que je puisse prendre possession de mon code (peut-être aurais-je dû dire "lacunes") et il n'a pas été réactif .
Je crains de ne pas être aussi agressif quand je lui demande de m'expliquer ses changements.
C'est juste une personne silencieuse qui reste seule, mais ses actions continuent. Je ne veux pas lui interdire de faire des changements de code (pas comme je pourrais), parce que 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 terminent une seule tâche car je risque de perdre un travail important - je m'assure donc que mes modifications se construisent et ne cassent rien.
- Ma préoccupation 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, j'ai pensé qu'il serait préférable de discuter des avantages et des inconvénients 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, sauf si cela est nécessaire. Comme ma préoccupation semblait plus un problème personnel 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 faire tout pour mes bêtes noires.
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 se rend compte à quel point ce sera frustrant quand il ou elle deviendra le senior et se sentira obligé de nettoyer le code écrit par les juniors.
Pour moi, éviter les conflits dans cette situation se résume à deux choses:
Courtoisie. Parler à quelqu'un de son code permet à un développeur de savoir que vous êtes intéressé et vous pouvez en discuter en tant que professionnel adulte.
Oubliez la "propriété du code" - l'équipe possède le code. D'autres personnes qui souhaitent apporter des modifications sont une bonne chose. Si un développeur senior apporte des modifications "illisibles" ou pire, annulez-les. Vous n'avez pas besoin d'être agressif, faites simplement savoir à un éditeur que ses modifications n'ont pas fonctionné et vous serez plus qu'heureux de discuter de votre réversion.
N'oubliez pas que l'appropriation du code par l'équipe est excellente et que cela 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 considérez cela 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 cassé qu'autre chose.
Tout d'abord, vous mentionnez que votre collègue est le commandant en second et qu'il devrait revoir votre code. C'est juste faux. Par définition, les revues de code par les pairs ne sont pas hiérarchiques et ne visent certainement pas seulement à trouver des défauts. Ils peuvent également offrir des expériences d'apprentissage (pour toutes les personnes impliquées), une opportunité d'interaction sociale et se révéler un outil précieux pour construire la propriété collective du code. Vous devriez également revoir son code de temps en temps, apprendre de lui et le corriger quand il a tort (personne ne le fait bien chaque fois).
De plus, vous mentionnez que votre collègue fait tout de suite des changements. C'est aussi faux, mais bien sûr, vous le savez déjà; vous n'auriez pas posé cette question si son approche gung ho n'était pas un problème. Cependant, je pense que vous cherchez une solution au mauvais endroit. Pour être parfaitement honnête, votre collègue me rappelle un peu ... moi, et ce qui a fonctionné pour moi dans des situations similaires a été un processus d'examen bien défini et solide et un ensemble d'outils impressionnants. Vous ne voulez pas vraiment empêcher votre collègue de revoir votre code et lui demander de s'arrêter et de vous parler avant que chaque petit changement ne fonctionne pas vraiment. Cela pourrait, pendant un certain temps, mais il atteindra bientôt un point où cela deviendra trop ennuyeux et vous reviendrez là où vous avez commencé, ou pire: il cessera simplement de réviser votre code.
La clé d'une résolution ici pourrait être un outil de révision de code par les pairs. J'évite généralement les recommandations de produits, mais pour les revues de code Crucible d'Atlassian est vraiment un épargnant de vie. Ce qu'il fait peut sembler très simple, et il l'est, mais cela ne signifie pas qu'il n'est pas incroyablement génial. Il se connecte à votre référentiel et vous donne la possibilité de revoir des modifications individuelles, des fichiers ou un groupe de fichiers. Vous ne pouvez modifier aucun code, mais vous commentez tout ce qui ne vous semble pas correct. 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 mérite d'être regardée si vous souhaitez plus de détails. Le prix de Crucible n'est pas pour tout le monde, mais il existe de nombreux outils d'évaluation par les pairs disponibles gratuitement. Celui avec lequel j'ai travaillé et apprécié est Review Board et je suis sûr que vous en trouverez beaucoup d'autres avec une simple recherche Google.
Quel que soit l'outil que vous choisissez, il changera complètement votre processus. Pas besoin de s'arrêter, de descendre de sa chaise, d'interrompre l'autre personne et de discuter des changements; il vous suffit de prendre un congé chaque semaine et de parcourir les commentaires (une fois par semaine n'est qu'une suggestion. Vous connaissez mieux votre emploi du temps et votre routine quotidienne que moi). Plus important encore, les principales critiques 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 lors de l'introduction d'un nouveau membre de l'équipe à notre base de code. C'est toujours bien quand je peux guider quelqu'un de nouveau à travers la base de code en indiquant où nous étions exactement coincés, où nous avions des opinions divergentes, etc.
Poursuivant, vous mentionnez 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 ce problème comme un problème de personnes ou vous pouvez le considérer comme un problème de processus, et je suggère 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 vous y teniez. De nombreux outils peuvent vous aider, mais c'est une toute autre discussion. Juste pour vous aider à démarrer, une chose très simple à faire est d'avoir un hook pré-commit exécuter une sorte de formateur de style sur votre code. Vous pouvez continuer à écrire votre code comme vous le souhaitez et laisser l'outil le "réparer" automatiquement avant que quiconque ne le voie.
Enfin, vous mentionnez dans n commentaire que la direction ne pense pas que des branches de développement individuelles soient nécessaires. Eh bien, il y a une raison pour laquelle nous les appelons "branches de développement" et non "branches de gestion". Je m'arrête ici car il n'y a aucune raison pour que la diatribe qui se forme dans ma tête sorte.
Cela dit, sachez que je ne doute pas que votre collègue soit (un peu) en faute ici. Ce n'est pas mon point, mon point est que tout votre processus de développement est également en faute, et c'est quelque chose qui est plus facile à réparer. Armez-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 vous rendrez compte 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 propose "nous sommes une petite équipe, nous n'avons pas besoin de toute cette excuse". Une équipe de développeurs compétents peut mettre en place les outils nécessaires en moins d'une semaine, automatiser tout ce qui peut être automatisé et ne jamais regarder en arrière.
PS. La "propriété du code" est un terme nébuleux, constamment débattu, et il signifie différentes choses pour différentes personnes. Vous pouvez trouver une brillante collection de la plupart des opinions divergentes (et parfois antithétiques) sur C2 .
Qu'est-ce qui vous donne envie de assumer la responsabilité pour "votre code"? Avez-vous la seule responsabilité de faire fonctionner certaines fonctionnalités? Le responsable a-t-il dit "Michael, je veux que tu prennes la responsabilité de ..."? Ou 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 rompues?
Quoi qu'il en soit, si vous en avez la responsabilité, vous devez avoir autorité sur le code. La prochaine fois que l'autre boursier apportera des modifications unilatérales et que le responsable vous reviendra pour les corriger, vous devriez vous asseoir avec le responsable et demander à ce que votre autorité et votre responsabilité soient alignées.
Non pas que cela résoudra toute la situation, mais vous pouvez essayer d'ajouter plus de commentaires à votre code source.
- Si le code n'est pas complet, il pourrait être marqué comme tel.
- Si l'objectif d'un bloc de code n'est pas auto-documenté, vous devez le documenter.
Dans l'ensemble, 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 sont pas là pour vous faire mal paraître. Essayez d'apprendre de vos erreurs et appliquez-les à de futures révisions.
Si vous pensez que ses changements ont un impact négatif, veuillez l'exprimer (diplomatiquement). Si c'était moi, je demanderais simplement pourquoi des modifications spécifiques ont été apportées et voir si vous pouvez défendre vos modifications d'origine. Vos collègues seniors sont également humains. Il est tout à fait possible qu'il ait manqué quelque chose et/ou qu'il n'ait pas conscience de tout impact négatif qu'il fournit.
Tout le monde implicitement "possède son propre code", indépendamment de la politique, des 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épond pas lorsque vous demandez un avertissement, ce collègue est pour le moins discourtois et peut-être essaie de vous affaiblir (pour dire le pire ...) - ne PAS ressemble à un joueur d'équipe.
Un bon collègue toucherait la base avec vous et soulignerait le problème avec votre code à vous - et vous laisserait le corriger/le changer, ou répondre de manière appropriée. Je suis très reconnaissant que même lorsque j'étais une nouvelle abeille, mes mentors m'ont toujours indiqué ce que je faisais de mal, expliqué pourquoi et laissé (ou fait) me corriger. Cela a fait de moi un meilleur programmeur et tout le monde en a profité. Et c'est ce que j'ai toujours fait lors de l'examen des travaux effectués par d'autres. Ensuite, vous (ou quiconque) apprenez réellement quelque chose de votre `` valet de tous les métiers '', et le code et l'équipe s'améliorent tous, y compris votre professeur: l'enseignement aide à comprendre.
Si c'est possible, je discuterais de la question en privé avec le chef d'équipe. D'après votre description de la situation, un bon chef d'équipe prendra votre parti - un mauvais ne le fera pas .. .. Évidemment, cela demande de la prudence - vous devrez en juger par vous-même.
Si vous écrivez du code, je devrais le revoir.
Si je change votre code pendant la révision, alors le code n'est plus le code que j'ai révisé, mais le code que j'ai changé. Il doit donc être revu. Probablement par vous.
Si je valide votre nouveau code avec mes modifications sans que quelqu'un ne révise mes modifications, alors j'ai commis (1) une modification non révisée et (2) le pire péché possible si les critiques de code sont prises au sérieux.
Je pense que vous le gérez de la bonne façon pour l'instant - mais il y aura bientôt un point de basculement où cela 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 tête-à-tête rapide avec cette personne et expliquerais mon PoV calmement mais fermement. La propriété du code, etc. par l'équipe est très bien, mais à moins que vous ne donniez à chaque développeur suffisamment d'espace pour publier son travail, faire des erreurs et s'améliorer, vous ne construirez jamais un bon code. Cela peut être une zone de friction plus tôt que tard.
(Il y a une réponse totalement différente si c'était sur le lieu de travail.stackexchange. Trouver la bonne façon de faire des revues de code est le plus simple. Convaincre votre collègue de s'y conformer est beaucoup plus difficile).