Donc votre senior et vous n'êtes pas d'accord sur ce que signifient les conventions de codage et de quelle manière est la plus lisible. La façon de résoudre ce problème est de clarifier votre compréhension afin que tout le monde soit sur la même page.

Par conséquent, j'aurais réagi comme suit:

S: Pourquoi êtes-vous Ce faisant? Vous changez mon code. Nous sommes une équipe ...

J: J'ai essayé de le faire adhérer à la convention de codage. Cela dit que nous devrions faire XXX, et améliorer le code existant quand nous le voyons?

Et ensuite écouter ce qu'il dit et essayer véritablement de comprendre son point de vue.

Et une fois que le débat technique est terminé (et que les esprits se sont, on l'espère, refroidis), j'aborderai l'aspect social de ses retours. Encore une fois, cela fonctionne mieux comme une question:

Que dois-je faire si je vois quelque chose dans votre code que je ne comprends pas ou que je pense qu'il pourrait être fait plus simple?

Et encore une fois écoutez ce qu'il veut.

Cela accomplit plusieurs choses:

1. Sa réponse plutôt émotionnelle indique qu'il est émotionnellement investi dans son code et ressent son jugement d'expert non respecté. En demandant son expertise, vous montrez que vous appréciez son expertise, ce qui devrait apaiser la discussion.
2. Cela signifie que vous ne vouliez pas lui manquer de respect ou faire étalage des normes sociales. Au contraire, cela lui fait comprendre que vous ne saviez tout simplement pas encore ce que vous attendiez de vous et que vous essayez de résoudre ce problème.
3. Cela clarifie ce que l'on attend de vous pour éviter d'autres conflits accidentels.

Lâchez prise. Vous essayez de faire un compromis entre 3 ou 4 priorités: vos préférences, les conventions du code, les préférences du développeur senior dont vous avez modifié le code et la capacité de l'équipe à donner du sens du code. Selon le développeur senior, son style de codage a du sens pour l'équipe. Les priorités 3 et 4 peuvent donc être combinées. Maintenant, c'est entre vous, les conventions de code et l'équipe senior dev +.

Entre ces options, les conventions de l'équipe et votre relation avec le développeur senior, à mon avis, comptent plus pour la capacité de l'équipe à faire le travail que vos préférences et les conventions du code.

En tenant compte du fait que vous êtes nouveau, je recommanderais de laisser tomber et d'en apprendre que ce que vous pensez être juste n'est pas nécessaire, ce qui devrait toujours arriver.

Je soupçonne d'autres ici pourraient repousser et il y a certainement de la place pour un ordre différent des priorités, mais c'est probablement la voie que j'aurais empruntée, du moins alors que j'étais encore un employé relativement nouveau. Bonne chance!

Vous avez déjà annulé les modifications. Alors laissez tomber.

Cela étant dit, la prochaine fois que cela se produira. Assurez-vous qu'il n'y a pas de marge de manœuvre avec votre interprétation des conventions de codage. Parce que, si vous allez avoir une bataille avec quelqu'un, assurez-vous de choisir une bataille que vous avez 100% de chances de gagner.

C'est important surtout si vous n'avez pas autant de capital social gestion comme cette personne l'a déjà.

Aussi, assurez-vous d'ajouter des tests unitaires avant de modifier trop de son code. Si vous introduisez des bogues dans son code, vous n'en entendrez jamais la fin. Et quand vous trouvez quelque chose de lui qui vaut la peine de changer. Ensuite, allez-y, mais soyez prudent et suivez les conventions officielles (et si ce n’est pas le cas, les conventions officielles ne traitent pas un problème particulier, suivez au moins les conventions Code Complete).

S'il se plaint à vous, alors vous pouvez simplement lui dire de se battre pour changer les conventions du code, et qu'une fois qu'il aura reçu l'approbation des nouvelles conventions de codage qu'il a à l'esprit, vous serez heureux de les examiner les mettre en œuvre, mais pas avant.

De plus, vous devriez probablement demander à la direction d'organiser des révisions hebdomadaires du code. Après tout, si vous avez l'occasion de discuter des décisions de codage lors des révisions de code. Cela vous donnera un moyen plus sûr et moins conflictuel de comprendre et / ou de contester les mauvaises habitudes de vos pairs.

Il se passe beaucoup de choses

Il y a pas mal de choses qui se passent ici. Beaucoup d’entre eux ont été abordés et je vais les mentionner brièvement ainsi que ma vision de ce que vous devriez ou ne devriez pas faire à leur sujet. Cependant, il y a un point que je n'ai pas encore vraiment vu abordé et que je considère comme le plus gros problème et je vais l'aborder plus en détail.

Bugs Corrections de style &

Vous avez corrigé le problème tout en changeant en même temps le code.

À mon avis, ce n'est pas un gros problème, mais il est généralement préférable de garder des choses séparées dans des commits séparés. Cela aurait également eu pour effet de séparer le conflit du correctif de bogue ici.

Vues différentes

Vous n'êtes pas d'accord sur la version qui suit le mieux les conventions, est plus lisible et est plus maintenable.

S'il est votre aîné, il serait peut-être bon de suivre son exemple à ce sujet. Sinon, il pourrait être bon que quelqu'un d'autre de l'entreprise examine le code avec vous deux, en le regardant sous ces trois perspectives.

Code difficile

Le le code était difficile à comprendre au début.

J'ai trouvé utile de poser des questions sur le code dans de telles situations, surtout si vous savez qui a écrit le code (et / ou le code a été écrit récemment). Poser des questions peut à la fois vous amener à mieux comprendre le code et aider l'autre personne à comprendre pourquoi le code était difficile à comprendre au départ. Cela évoque souvent des moyens de rendre le code plus clair tout seul, ce que vous pouvez ensuite discuter avant de les implémenter.

L'attaque

L'autre personne devient assez agressive en suggérant que vous doivent se séparer et qu'ils s'adressent à votre responsable pour que vous n'ayez pas accès à certains codes.

Tel qu'écrit, c'est assez sérieux. Cela dépend un peu de la façon dont la différence entre les choses réelles qu'il a dites et la façon dont vous l'avez paraphrasé ici oscille, mais purement par la façon dont vous l'avez écrite, cela devrait être une raison à elle seule de parler à votre responsable. Si vous le faites, ne parlez pas du code, mais de son attitude envers vous où il semble envisager de vous menacer.

Son code

Il ne veut pas que vous modifiiez son code.

À mon avis, c'est le plus gros problème. C'est une attitude assez toxique et je pense que cela touche au cœur du problème. Les programmeurs amateurs sont souvent très protecteurs de leur code et parfois cela peut être vu avec des programmeurs professionnels qui ont également travaillé sur le code par eux-mêmes. Cependant, il n'a sa place dans aucun cadre professionnel et est extrêmement toxique lorsque vous êtes responsable du code en équipe.

En fin de compte, le problème est que le code n'est pas le sien. Le code appartient à l'entreprise ou peut-être à l'équipe, mais ce n'est pas le sien. Au lieu de cela, c'est du code qu'il a écrit. Je pense qu'il est important de ne pas l'appeler comme son code, mais comme un code qu'il a écrit. Sans dire que ce n'est pas son code ou sans le corriger quand il dit que c'est son code, il peut être avantageux de s'y référer systématiquement comme du code qu'il a écrit vous-même. Cela vaut à la fois pour le moment où vous discutez de la situation avec lui, ainsi que pour discuter de la situation avec d'autres membres de l'équipe ou un manager.

Tout d'abord, je dirais que je laisserais cet incident soyez ce que c'est pour le moment. Cependant, je ne ferais pas non plus tout mon possible pour éviter de toucher au code qu'il a écrit à l'avenir. On dirait que ça va être une chose qui va revenir et marcher sur des œufs toute la journée ne va pas aider personne.

En supposant que vous faites partie d'une équipe avec plus de membres que vous deux, la première chose à faire est de parler du problème aux autres membres de l'équipe. Demandez-leur s'ils ont vécu le même comportement et comment ils l'ont géré ou le feraient. Vos collègues sont une ressource qu'il ne faut pas sous-estimer. S'il n'y a pas d'autres membres dans votre équipe, vous pouvez à la place demander à d'autres collègues qui ont eu à travailler avec cette personne dans le passé.

Ensuite, si ce programmeur s'avère surprotecteur du code qu'il a écrit à une autre occasion, essayez d'appliquer les suggestions de vos collègues. Au-delà de cela, vous pouvez également lui demander s'il est contrarié parce que vous avez changé le code qu'il a écrit ou que c'est qu'il pense que le changement affecte négativement le code. Ce sont deux problèmes complètement distincts et il est important de lui faire savoir qu'ils le sont.

Après ce point, il semble qu'il serait temps de faire remonter le problème. Parlez à votre chef d'équipe ou à votre responsable (selon ce qui est le plus approprié) et expliquez-leur que cette personne semble avoir du mal à ce que vous touchiez le code qu'elle a écrit. Bien que vous soyez ouvert à la discussion sur la qualité de tout code (ce que vous devriez être), il semble que cela semble être le fait que cette personne souhaite que le code qu'il a écrit ne soit pas touché (par vous - si c'est ce que vous pensez est). Expliquez comment cela répartit à tort la propriété, la responsabilité et la compréhension du code et comment cela nuit au produit et augmente la façon dont l'entreprise s'appuie sur des personnes spécifiques. (Bien sûr, une telle explication ne devrait pas avoir besoin d'être aussi détaillée quand on parle à un chef d'équipe que lorsqu'on parle à un manager.)

En conclusion

Donc, essentiellement, Je pense que le plus important est de séparer les différents problèmes et de les aborder individuellement. Cela devrait également rendre beaucoup plus facile de gérer chacun d'eux, car vous savez maintenant ce qui se passe.

J'ai vu un certain nombre de réponses disant "Laissez-le aller". Je ne peux pas être d'accord avec cela, car le problème va se poser encore et encore.

Une équipe a besoin de normes, en particulier pour éviter de tels arguments. Je dirais de parler à nouveau à votre collègue, une fois que les esprits se sont un peu calmés. Demandez-lui de passer en revue les normes de codage avec vous et déterminez ensemble - si possible - comment vous pensez que le code devrait être organisé. Si vous arrivez à un accord, coolio. Si ce n'est pas le cas, reconnaissez sans rancune que vous n'êtes tout simplement pas sur la même page, et demandez au responsable de vous aider à résoudre le problème.

Vous avez supprimé votre exemple spécifique (que j'ai trouvé dommage, il offre un peu de contexte), mais laissez-moi juste ajouter une chose ... Cette partie potentiellement délicate (incrémenter le nombre de modules d'index pour revenir à 0) devrait être compréhensible pour J Random Programmer, mais cela ne ferait pas de mal de tomber dans un quickie commentaire en haut de la ligne comme rappel ...; D

Je ne pense pas que vous puissiez laisser tomber cela: votre collègue est très protecteur du code qu'il a écrit. Ainsi, chaque fois que vous changez un morceau de code qu'il a écrit et qu'il n'a pas de bogue, il est très susceptible de venir vous en "parler".

Et votre collègue essaie de vous intimider, ne vous y trompez pas.

Tout d'abord , le code sur lequel vous travaillez tous les deux n'est ni le sien ni le vôtre. Il appartient à celui qui vous paie.

Deuxièmement , vous ne devriez pas faire ce qu'il dit que vous devriez faire, à moins qu'il ne soit votre patron, ce qu'il n'est pas. Vous devez faire ce que votre employeur veut que vous fassiez.

Troisièmement , je suis d'accord avec vous pour dire que vous devriez laisser les choses mieux que ce que vous avez trouvé, donc rendre le code plus lisible est bonne chose.

Donc, vous ne voulez pas vous compliquer la vie pour 3 lignes de code. Bien sur vous! Mais qu'allez-vous faire la prochaine fois que cela se produira?

Je suggère d'impliquer votre chef d'équipe / manager la prochaine fois que cela se produira. Voir les points, un, deux et trois.

Bien que votre homologue "senior" ait réagi de manière excessive, vous devriez également envisager la possibilité qu'il ait eu raison d'une certaine manière.

Malheureusement, les modifications ont supprimé le code lui-même: c'est peut-être généralement mieux pour la plupart des utilisateurs non informatiques, mais dans ce cas, une information importante a été perdue.

À mon avis, vous avez amélioré la lisibilité du code par la plupart des métriques formelles: les conditions sont organisées de manière plus logique, il y a des accolades et des trucs. Cependant, votre introduction de l'opérateur % (reste entier) est une astuce intelligente qui déroutera 90% des développeurs juniors, et apparemment aussi certains seniors. Maintenant, le code trop verbeux est mauvais, les contrôles redondants sont mauvais, mais les astuces intelligentes sont tout simplement horribles, à moins que vous ne soyez sûr que tous les développeurs sont au moins aussi intelligents que vous. Et vous avez déjà la preuve qu'ils ne le sont pas.

De plus, bien que les documents de votre entreprise indiquent que vous devez "corriger le code qui n'est pas écrit avec ce style", il serait probablement préférable de mentionner de tels changements à l’auteur original, s’il ou elle est disponible. Un message rapide du type "Ecoutez, j'ai eu des problèmes pour déboguer ce code, ne pensez-vous pas qu'il est plus lisible de cette façon?" aurait pu vous éviter à tous les deux l'embarras.

Lorsque vous êtes nouveau, c'est généralement une bonne idée de prendre le temps d'observer la dynamique et de vous faire une idée de l'équipe, etc. avant de prendre sur vous de faire de grands changements. Une bonne règle de base est "Si ce n'est pas cassé, ne le réparez pas", ou un corollaire à cela, "S'il était cassé, quelqu'un l'aurait déjà réparé." Si le code en question était un gros problème, il aurait probablement (ou du moins aurait dû être corrigé maintenant. Il est possible que certains codes que vous rencontrez à ce travail doivent être corrigés, mais attendez vous êtes plus familier avec le système du groupe avant de décider si un tel code est éligible.

Malgré les efforts déployés pour développer des normes universelles de codage / documentation, CHAQUE LIEU DE TRAVAIL AURA LEURS PROPRES NORMES et il faut du temps pour déduire de quoi il s'agit exactement.

Vous pourriez laisser passer cet incident, mais vous ne devriez pas avoir tort. Il vous suffit de choisir vos batailles.

Votre mentalité est absolument correcte. Chaque fois que nous revisitons l'ancien code, s'il n'est pas facile à maintenir, nous devons d'abord comprendre. Une fois que cette compréhension a été réalisée, si nous ne documentons pas ou ne facilitons pas la voie vers cette compréhension, nous perdons le temps d'autres mainteneurs sur la route, tout comme le programmeur d'origine vous a fait baisser ce coût. C'est donc le devoir de tout programmeur digne de ce nom de documenter ou d'améliorer le code au fur et à mesure (ce dernier est moins risqué lorsque vous avez une suite de tests robuste et exhaustive qui garantit que les refacteurs et les améliorations ne brisent pas la fonctionnalité). Laisser des commentaires n'est pas idéal, mais cela laisse l'impression que le code a besoin d'un peu d'amour à l'avenir.

Votre équipe adopte également la bonne approche des conventions de codage. Les conventions ne sont pas des règles, il doit donc y avoir une certaine marge de manœuvre pour les enfreindre lorsqu'il est logique de le faire. Mais ils représentent un idéal qui n'a peut-être pas toujours été atteint et il est plus pratique d'appliquer des conventions de code sur du code nouveau et mis à jour plutôt que de le refactoriser de manière exhaustive. Dans un projet idéal, le code ne devrait jamais ressembler à un individu spécifique qui l'a écrit. Cela permet à tous les développeurs de vérifier leur ego à la porte et de traiter le code comme le code de l'équipe, se soucier de la qualité du code plutôt que de qui a écrit quoi.

Ceci nous amène à votre collègue. Leur comportement n'est pas inhabituel comme vous pourriez le penser, car les programmeurs ont tendance à ressentir de la fierté et à s'approprier leur code (ou cherchent à blâmer les autres, parfois, uniquement pour se voir dans l'histoire) et peuvent développer leur ego malgré les efforts pour résister. . D'autres ne résistent pas du tout. "Mon code" est une mauvaise attitude à avoir, tout le code doit appartenir à l'équipe. Il y a une incohérence entre son affirmation selon laquelle il a codé des choses pour être compréhensibles par l'équipe si cela contrevient aux directives de codage de l'équipe. Il dit clairement que c'est codé pour être compréhensible par lui d'abord, pas par l'équipe, et il est contrarié que vous ayez ruiné sa compréhension en ayant l'audace de changer les choses (tout bon code doit être écrit pour être facile à maintenir et à supprimer, pas immortel).

Cela empire quand il prétend que vous ne pouvez jamais comprendre son code et menace d'utiliser son influence pour vous mettre hors de votre travail. Cela seul est extrêmement peu professionnel, mais en réponse à un peu de formatage, il est extrêmement démesuré.

Vous devez choisir vos batailles et je laisserais le côté formatage des choses aller. Si vous êtes nouveau dans l'équipe et que quelqu'un dit que vous ne respectez pas la convention de code, tout ce que vous pouvez vraiment faire est de vous en remettre à son expérience et de vous suggérer de mettre à jour la documentation si elle est devenue trompeuse. Si cela cause des frictions, alors vous devez faire appel à votre patron car le fait de garder une norme sur papier et une autre dans la pratique (en particulier à la demande de développeurs individuels) est discordant et minant.

Cependant, je serais beaucoup plus susceptible de me concentrer sur la menace qui vous est adressée. Si cela a été fait verbalement, vous n'avez pas de bonnes preuves à ce stade et vous n'avez pas de bonne option pour agir à ce stade, mais je serais très prudent avec lui à l'avenir et j'essaierais d'obtenir tout ce qu'il dit par écrit, par exemple. interagissez autant que possible par e-mail. S'il vous menace à nouveau par écrit, vous pouvez commencer à en parler à votre patron. D'après les sons des choses, son ego est suffisamment fragile pour que vous ayez à nouveau des problèmes avec lui, tôt ou tard.

Là où vous pourriez rencontrer des problèmes, c'est que vous ne connaissez pas le profane de la terre. Si ce type est vraiment aussi mauvais qu'il le parait, il est possible que de larges pans de code aient été écrits par lui et soient devenus impossibles à maintenir par quiconque sauf lui. En tant que tel, il s'est effectivement rendu indésirable car l'entreprise ne peut se permettre de le perdre, ce qui a permis son mauvais comportement. Cela peut être bon à court et moyen terme pour la sécurité de l'emploi, mais à long terme, cela dégénère, contre-productif et peut ruiner votre réputation. N'aspirez pas à cela.

Dans cet esprit, veillez à ne pas mettre l'entreprise en position de choisir car elle mettra les intérêts de l'entreprise au premier plan. Traitez votre emploi actuel comme une expérience d'apprentissage pour faire face à des personnes difficiles. Passez du temps avec vos collègues et découvrez comment ils traitent ce type et ne laissez pas passer l'opportunité d'apprendre d'autres choses d'eux aussi. En attendant, gardez un œil sur les autres opportunités et soyez prêt à atterrir sur vos pieds au cas où il aurait de l'influence et vous expulserait pour une autre infraction perçue.

La réponse à cette question dépend fortement de l'approche générale de «l'adhésion au processus» au sein de l'entreprise, et vous devriez déjà en avoir une idée.

J'ai travaillé dans une entreprise qui était, sur papier, certifié ISO9001, mais le PDG nous a toujours mis sur écoute avec des demandes de devis faites par des appels téléphoniques rapides et incomplets, même si nous avions un formulaire de demande où toutes les informations pouvaient être collectées. Vous pensez probablement que dans ce cas, l'application de la norme était une bataille perdue.

Vous avez deux alternatives:

1. L'entreprise a une culture d'adhésion aux processus : vous avez raison de suivre la convention de codage de l'entreprise, et si la situation s'aggrave, indiquez simplement que vous avez suivi la norme.
2. L'adhésion au processus est sur papier : oubliez le manuel, et suivez le "conseil" de ce senior.

"La convention de code dit clairement que je peux changer le code pour le rendre dans l'esprit de la convention de code. La convention a été écrite par son responsable direct."

Je ne peux m'empêcher de penser que c'est Une directive terrible. Par tous les moyens, générer un ticket pour "améliorer" une section spécifique du code, ou le mettre à niveau, mais "le changer si vous n'aimez pas son apparence" est une recette pour le désastre. Comment contrôlez-vous ces modifications lorsqu'elles sont effectuées dans le cadre d'un autre correctif? Comment testez-vous les changements?

Pour autant que je vois votre problème avec le code de vos pairs, c'est la convention de code formelle dont vous avez une compréhension différente de celle du senior.

Il existe de nombreux outils qui formateront automatiquement le code pour vous par un ensemble de règles configurables. Ils ne laissent pas beaucoup de place pour interpréter les conventions.

Ainsi, lors d'une réunion d'équipe régulière (une scrum-rétrospective de préférence), vous pouvez faire référence à votre discussion avec le senior et vous dire que vous vous sentez mécontent de la situation, puis suggérez que votre équipe (ou au moins vous) commence en utilisant un tel formateur automatique et nommez le senior pour configurer l'ensemble de règles.

La prochaine fois que vous changez le code des seniors (pour corriger un bug), le reformatage est effectué par un outil qu'il a configuré. Je suis curieux de savoir comment il peut vous blâmer alors ...