Ihr Senior und Sie sind sich also nicht einig darüber, was die Codierungskonventionen bedeuten und welcher Weg besser lesbar ist. Die Möglichkeit, dies zu beheben, besteht darin, Ihr Verständnis zu klären, damit alle auf derselben Seite sind.

Daher hätte ich wie folgt reagiert:

S: Warum sind Sie? Dies tun? Sie ändern meinen Code. Wir sind ein Team ...

J: Ich habe versucht, die Codierungskonvention einzuhalten. Es heißt, wir sollten XXX machen und vorhandenen Code verbessern, wenn wir ihn sehen?

Und dann hören Sie sich an, was er sagt, und versuchen Sie wirklich, seinen Standpunkt zu verstehen.

Und sobald die technische Debatte vorbei ist (und die Gemüter hoffentlich abgekühlt sind), würde ich auf die soziale Seite seines Feedbacks eingehen. Auch dies funktioniert am besten als Frage:

Was soll ich tun, wenn ich etwas in Ihrem Code sehe, das ich nicht verstehe oder für einfacher halte?

Und hören Sie noch einmal zu, was er will.

Damit werden mehrere Dinge erreicht:

1. Seine eher emotionale Reaktion zeigt an, dass er emotional in seinen Code investiert ist und sein Expertenurteil spürt nicht respektiert. Indem Sie nach seinem Fachwissen fragen, zeigen Sie, dass Sie sein Fachwissen schätzen, was die Diskussion beruhigen sollte.
2. Es bedeutet, dass Sie ihn nicht missachten oder soziale Normen zur Schau stellen wollten. Vielmehr wird ihm klar, dass Sie einfach noch nicht wussten, was von Ihnen erwartet wurde, und dass Sie versuchen, dies zu beheben.
3. Es wird klargestellt, was von Ihnen erwartet wird, um weitere versehentliche Konflikte zu vermeiden.
ol>

Lassen Sie es los. Sie versuchen, einen Kompromiss zwischen drei oder vier Prioritäten einzugehen: Ihren Präferenzen, den Codekonventionen, den Präferenzen des leitenden Entwicklers, dessen Code Sie geändert haben, und der Fähigkeit des Teams, einen Sinn zu ergeben des Codes. Laut dem leitenden Entwickler macht sein Codierungsstil für das Team Sinn. So können die Prioritäten 3 und 4 kombiniert werden. Jetzt ist es zwischen Ihnen, den Code-Konventionen und dem Senior Dev + Team.

Zwischen diesen Optionen sind meiner Meinung nach die Konventionen des Teams und Ihre Beziehung zum leitenden Entwickler für die Fähigkeit des Teams, die Arbeit zu erledigen, wichtiger als Ihre Präferenz und die Code-Konventionen.

Wenn Sie berücksichtigen, dass Sie neu sind, würde ich empfehlen, es loszulassen und daraus zu lernen, dass das, was Sie für richtig halten, nicht notwendig ist, was immer passieren sollte.

Ich vermute andere hier könnten zurückschieben und es gibt definitiv Raum für eine andere Reihenfolge der Prioritäten, aber dies ist wahrscheinlich der Weg, den ich eingeschlagen hätte, zumindest als ich noch ein relativ neuer Mitarbeiter war. Viel Glück!

Sie haben die Änderungen bereits rückgängig gemacht. Also lass es los.

Davon abgesehen, wenn dies das nächste Mal passiert. Stellen Sie sicher, dass bei der Interpretation der Codierungskonventionen kein Spielraum vorhanden ist. Wenn Sie mit jemandem kämpfen möchten, wählen Sie unbedingt einen Kampf aus, bei dem Sie eine 100% ige Gewinnchance haben.

Dies ist besonders wichtig, wenn Sie nicht so viel soziales Kapital haben Management wie diese Person bereits hat.

Stellen Sie außerdem sicher, dass Sie Komponententests hinzufügen, bevor Sie zu viel von seinem Code ändern. Wenn Sie Fehler in seinen Code einführen, werden Sie nie das Ende davon hören. Und wenn Sie etwas von ihm finden, lohnt es sich, es zu ändern. Dann machen Sie weiter, aber seien Sie vorsichtig und befolgen Sie die offiziellen Konventionen (und wenn nicht, behandeln die offiziellen Konventionen kein bestimmtes Problem, befolgen Sie mindestens die Konventionen Code Complete).

Wenn er sich bei Ihnen beschwert, können Sie ihm einfach sagen, dass er bei der Änderung der Codekonventionen kämpfen soll. Sobald er die Genehmigung für diese neuen Codierungskonventionen erhalten hat, die er im Auge hat, werden Sie sie gerne ansehen und implementieren sie, aber nicht vorher.

Außerdem sollten Sie das Management wahrscheinlich bitten, wöchentliche Codeüberprüfungen zu organisieren. Immerhin, wenn Sie die Möglichkeit haben, Codierungsentscheidungen während der Codeüberprüfung zu besprechen. Dies gibt Ihnen eine sicherere und weniger konfrontative Möglichkeit, einige der schlechten Gewohnheiten Ihrer Kollegen zu verstehen und / oder herauszufordern.

Es ist viel los

Hier ist einiges los. Viele davon wurden angesprochen, und ich werde sie und meine Vision, was Sie dagegen tun sollten oder nicht, kurz erwähnen. Es gibt jedoch einen Punkt, den ich noch nicht wirklich angesprochen habe, den ich als das größte Problem betrachte, und ich werde ihn genauer behandeln.

Fehler Korrekturen im &-Stil

Sie haben behoben das Problem bei gleichzeitiger Änderung des Codes.

Meiner Meinung nach ist dies kein großes Problem, aber es ist im Allgemeinen besser, getrennte Dinge in getrennten Commits zu halten. Dies hätte dazu geführt, dass der Konflikt auch hier von der Fehlerbehebung getrennt wurde.

Unterschiedliche Ansichten

Sie sind sich nicht einig darüber, welche Version den Konventionen besser entspricht, besser lesbar und besser ist wartbar.

Wenn er Ihr Senior ist, kann es gut sein, seinem Beispiel zu folgen. Alternativ kann es gut sein, wenn jemand anderes aus dem Unternehmen gemeinsam mit Ihnen beiden den Code aus diesen drei Perspektiven betrachtet.

Starker Code

Der Code war anfangs schwer zu verstehen.

Ich fand es nützlich, in solchen Situationen Fragen zum Code zu stellen, insbesondere wenn Sie wissen, wer den Code geschrieben hat (und / oder der Code geschrieben wurde) vor kurzem). Das Stellen von Fragen kann dazu führen, dass Sie den Code besser verstehen und der anderen Person helfen, zu erkennen, warum der Code anfangs schwer zu verstehen war. Dies führt häufig dazu, wie der Code von selbst klarer gemacht werden kann, was Sie dann besprechen können, bevor Sie ihn implementieren.

Der Angriff

Die andere Person wird ziemlich aggressiv, indem sie Ihnen vorschlägt Sie müssen sich trennen und dass sie zu Ihrem Manager gehen, um Sie von bestimmten Codes fernzuhalten.

Wie geschrieben, ist das ziemlich ernst. Es hängt ein wenig davon ab, auf welche Weise der Unterschied zwischen den tatsächlichen Dingen, die er gesagt hat, und der Art und Weise, wie Sie ihn hier umschrieben haben, schwankt, aber allein durch die Art und Weise, wie Sie es geschrieben haben, sollte dies allein Grund sein, mit Ihrem Manager zu sprechen. Wenn Sie dies tun, machen Sie es nicht mit dem Code, sondern mit seiner Einstellung zu Ihnen, wo er in Erwägung zu ziehen scheint, Drohungen gegen Sie in Ordnung zu bringen

Er möchte nicht, dass Sie seinen Code bearbeiten.

Meiner Meinung nach ist dies das größte Problem. Dies ist eine ziemlich giftige Einstellung, und ich denke, sie trifft den Kern des Problems. Hobby-Programmierer schützen ihren Code oft sehr und manchmal kann dies bei professionellen Programmierern beobachtet werden, die auch selbst an Code gearbeitet haben. Es hat jedoch keinen Platz in einer professionellen Umgebung und ist extrem giftig, wenn Sie als Team für den Code verantwortlich sind.

Letztendlich besteht das Problem darin, dass der Code nicht von ihm stammt. Der Code gehört dem Unternehmen oder vielleicht dem Team, aber nicht seinem. Stattdessen ist es Code, den er geschrieben hat. Ich denke, es ist wichtig, es nicht als seinen Code zu bezeichnen, sondern als Code, den er geschrieben hat. Ohne anzugeben, dass es nicht sein Code ist oder ihn zu korrigieren, wenn er sagt, dass es sein Code ist, kann es vorteilhaft sein, ihn konsequent als Code zu bezeichnen, den er selbst geschrieben hat. Dies gilt sowohl für den Moment, in dem Sie die Situation mit ihm besprechen, als auch für die Besprechung der Situation mit anderen Teammitgliedern oder einem Manager.

Zunächst würde ich sagen, dass ich diesen Vorfall zulassen würde sei was es jetzt ist. Ich würde jedoch auch nicht aus dem Weg gehen, um zu vermeiden, Code zu berühren, den er in Zukunft geschrieben hat. Es hört sich so an, als würde dies wieder auftauchen und das Gehen auf Eierschalen den ganzen Tag wird niemandem helfen.

Angenommen, Sie befinden sich in einem Team mit mehr Mitgliedern als Sie beide. Als Erstes können Sie mit anderen Teammitgliedern über das Problem sprechen. Fragen Sie sie, ob sie das gleiche Verhalten erfahren haben und wie sie damit umgegangen sind oder damit umgehen würden. Ihre Mitarbeiter sind eine nicht zu unterschätzende Ressource. Wenn Ihr Team keine anderen Mitglieder enthält, können Sie stattdessen andere Kollegen fragen, die in der Vergangenheit mit dieser Person gearbeitet haben.

Wenn sich herausstellt, dass dieser Programmierer den von ihm geschriebenen Code übermäßig schützt Versuchen Sie bei einer anderen Gelegenheit, die Vorschläge Ihrer Kollegen anzuwenden. Darüber hinaus können Sie ihn auch fragen, ob er verärgert ist, weil Sie den von ihm geschriebenen Code geändert haben oder dass er der Meinung ist, dass die Änderung den Code negativ beeinflusst. Dies sind zwei völlig getrennte Probleme, und es ist wichtig, ihn darauf aufmerksam zu machen.

Nach diesem Zeitpunkt scheint es an der Zeit zu sein, das Problem zu eskalieren. Sprechen Sie mit Ihrem Teamleiter oder Manager (je nachdem, was angemessener ist) und erklären Sie ihm, dass diese Person Probleme damit zu haben scheint, dass Sie den von ihnen geschriebenen Code berühren. Während Sie offen für Diskussionen über die Qualität eines Codes sind (was Sie sein sollten), scheint es die Tatsache zu sein, dass diese Person möchte, dass der Code, den sie geschrieben hat, nicht berührt wird (von Ihnen - wenn es Ihr Eindruck ist ist). Erklären Sie, wie dies fälschlicherweise das Eigentum, die Verantwortung und das Verständnis des Codes aufteilt und wie sich dies nachteilig auf das Produkt auswirkt und die Art und Weise erhöht, in der sich das Unternehmen auf bestimmte Personen verlässt. (Natürlich sollte eine solche Erklärung im Gespräch mit einem Teamleiter nicht annähernd so detailliert sein wie im Gespräch mit einem Manager.)

Abschließend

Also im Wesentlichen Ich denke, das Wichtigste ist, die verschiedenen Themen zu trennen und sie individuell anzugehen. Dies sollte es auch viel einfacher machen, mit jedem von ihnen umzugehen, da Sie jetzt wissen, was los ist.

Ich habe eine Reihe von Antworten mit der Aufschrift "Lass es los" gesehen. Dem kann ich nicht zustimmen, da das Problem immer wieder auftauchen wird.

Ein Team braucht Standards, um solche Argumente zu vermeiden. Ich würde sagen, Sie sollten noch einmal mit Ihrem Kollegen sprechen, sobald die Gemüter etwas nachgelassen haben. Bitten Sie ihn, die Codierungsstandards mit Ihnen zu besprechen und gemeinsam - wenn möglich - herauszufinden, wie der Code Ihrer Meinung nach organisiert sein sollte. Wenn Sie sich einigen können, coolio. Wenn nicht, erkennen Sie ohne Groll, dass Sie sich nicht auf derselben Seite befinden, und lassen Sie sich von dem Manager bei der Lösung des Problems helfen.

Sie haben Ihr spezielles Beispiel gelöscht (was ich für schade hielt, bietet es einige Zusammenhänge), aber lassen Sie mich nur eines hinzufügen ... Dieser eine möglicherweise schwierige Teil (Erhöhen der Index-Modulo-Anzahl, um wieder auf 0 zu kommen) sollte für J Random Programmer verständlich sein, aber es würde nicht schaden, einen Quickie einzuspielen Kommentar oben in der Zeile als Erinnerung ...; D

Ich glaube nicht, dass Sie das loslassen können: Ihr Kollege schützt den Code, den er geschrieben hat, sehr. Jedes Mal, wenn Sie einen Code ändern, den er geschrieben hat und der keinen Fehler aufweist, wird er sehr wahrscheinlich mit Ihnen darüber sprechen.

Und Ihr Kollege versucht, Sie zu schikanieren. Machen Sie hier keinen Fehler.

Zunächst einmal ist der Code, an dem Sie beide arbeiten, weder sein noch Ihr Code. Es gehört demjenigen, der Sie bezahlt.

Zweitens sollten Sie nicht tun, was er sagt, dass Sie tun sollten, es sei denn, er ist Ihr Chef, was er nicht ist. Sie sollten tun, was Ihr Arbeitgeber von Ihnen verlangt.

Drittens Ich stimme Ihnen zu, dass Sie die Dinge besser belassen sollten als das, was Sie gefunden haben, damit der Code besser lesbar ist Gute Sache.

Sie möchten Ihr Leben also nicht für 3 Codezeilen komplizieren. Gut auf dich! Aber was werden Sie tun, wenn dies das nächste Mal passiert?

Ich schlage vor, Ihren Teamleiter / Manager beim nächsten Mal einzubeziehen. Siehe Punkte eins, zwei und drei.

Während Ihr "älterer" Peer möglicherweise überreagiert hat, sollten Sie auch die Möglichkeit in Betracht ziehen, dass er in gewisser Weise Recht hatte.

Leider haben die Änderungen den Code selbst entfernt: Vielleicht ist dies für die meisten in der Regel besser Nicht-IT-Benutzer, aber in diesem Fall ging eine wichtige Information verloren.

Aus meiner Sicht haben Sie die Lesbarkeit von Code durch die meisten formalen Metriken verbessert: Die Bedingungen sind logischer organisiert. Es gibt Zahnspangen und so. Ihre Einführung des Operators % (ganzzahliger Rest) ist jedoch ein cleverer Trick, der 90% der Nachwuchsentwickler und anscheinend auch einige Senioren verwirren wird. Übermäßig ausführlicher Code ist schlecht, redundante Überprüfungen sind schlecht, aber clevere Tricks sind einfach schrecklich, es sei denn, Sie sind sicher, dass alle Entwickler mindestens so clever sind wie Sie. Und Sie haben bereits den Beweis, dass dies nicht der Fall ist.

Auch wenn in Ihren Unternehmensdokumenten angegeben ist, dass Sie "Code korrigieren sollten, der nicht mit diesem Stil geschrieben wurde", ist es wahrscheinlich besser, dies zu erwähnen solche Änderungen am ursprünglichen Autor, wenn er oder sie verfügbar ist. Eine kurze Nachricht im Sinne von "Schau, ich hatte Probleme beim Debuggen dieses Codes. Glaubst du nicht, dass er auf diese Weise besser lesbar ist?" hätte euch beiden etwas peinlich sein können.

Wenn Sie neu sind, ist es normalerweise eine gute Idee, sich etwas Zeit zu nehmen, um die Dynamik zu beobachten und ein Gefühl für das Team usw. zu bekommen, bevor Sie es auf sich nehmen, große Änderungen vorzunehmen. Eine gute Faustregel lautet: "Wenn es nicht kaputt ist, reparieren Sie es nicht" oder eine Folge davon: "Wenn es kaputt wäre, hätte es inzwischen jemand repariert." Wenn der fragliche Code ein großes Problem wäre, würde er wahrscheinlich (oder zumindest sollte inzwischen behoben sein. Es ist möglich, dass ein Code, auf den Sie bei diesem Job stoßen, repariert werden muss, aber warten Sie bis Sie sind mit dem System der Gruppe besser vertraut, bevor Sie entscheiden, ob ein solcher Code geeignet ist.

Trotz des Aufwands für die Entwicklung universeller Kodierungs- / Dokumentationsstandards hat JEDER ARBEITSPLATZ IHRE EIGENEN STANDARDS und es braucht Zeit, um zu schließen, was genau das ist.

Sie könnten diesen Vorfall loslassen, aber Sie sollten sich nicht falsch fühlen. Sie müssen nur Ihre Schlachten auswählen.

Ihre Mentalität ist absolut korrekt. Wann immer wir alten Code erneut besuchen, müssen wir zuerst verstehen, wenn es nicht einfach zu warten ist. Sobald dieses Verständnis erreicht ist und wir den Weg zu diesem Verständnis nicht dokumentieren oder vereinfachen, verschwenden wir die Zeit weiterer Betreuer, ähnlich wie der ursprüngliche Programmierer diese Kosten auf Sie herabgestuft hat. Daher ist es die Pflicht eines jeden Programmierers, Code zu dokumentieren oder zu verbessern (letzteres ist weniger riskant, wenn Sie über eine robuste und umfassende Testsuite verfügen, die sicherstellt, dass Refaktoren und Verbesserungen die Funktionalität nicht beeinträchtigen). Das Hinterlassen von Kommentaren ist nicht ideal, aber es hinterlässt den Geruch, dass der Code in Zukunft etwas Liebe braucht.

Ihr Team geht auch bei Codierungskonventionen richtig vor. Konventionen sind keine Regeln, daher muss es einen gewissen Spielraum geben, sie zu brechen, wenn dies sinnvoll ist. Sie stellen jedoch ein Ideal dar, das möglicherweise nicht immer erreicht wurde, und es ist praktischer, Codekonventionen für neuen und aktualisierten Code durchzusetzen, als eine umfassende Umgestaltung vorzunehmen. In einem idealen Projekt sollte der Code niemals so aussehen, wie ihn eine bestimmte Person geschrieben hat. Auf diese Weise können alle Entwickler ihr Ego an der Tür überprüfen und den Code als Code des Teams behandeln. Dabei müssen sie sich eher um die Codequalität kümmern als darum, wer was geschrieben hat.

Dies bringt uns zu Ihrem Kollegen. Ihr Verhalten ist nicht ungewöhnlich, wie Sie vielleicht denken, da Programmierer dazu neigen, stolz und eigenverantwortlich auf ihren Code zu sein (oder manchmal andere zu beschuldigen, nur um sich selbst in der Geschichte zu sehen) und trotz der Bemühungen, sich dagegen zu wehren, das Ego entwickeln können . Andere widersetzen sich überhaupt nicht. "Mein Code" ist eine schlechte Einstellung, der gesamte Code sollte dem Team gehören. Es gibt eine Inkonsistenz zwischen seiner Behauptung, dass er Dinge so codiert hat, dass sie für das Team verständlich sind, wenn dies gegen die Codierungsrichtlinien des Teams verstößt. Er macht deutlich, dass es so codiert ist, dass es zuerst für ihn und nicht für das Team verständlich ist, und er ist verärgert darüber, dass Sie sein Verständnis durch die Kühnheit, Dinge zu ändern, ruiniert haben (jeder gute Code sollte so geschrieben sein, dass er leicht zu warten und zu löschen ist). nicht unsterblich sein).

Es wird schlimmer, wenn er behauptet, dass Sie seinen Code nie verstehen können und droht, seinen Einfluss zu nutzen, um Sie aus Ihrem Job zu entlassen. Das allein ist massiv unprofessionell, aber als Reaktion auf ein wenig Formatierung wird es enorm überproportional.

Sie müssen Ihre Schlachten auswählen und ich würde die Formatierungsseite der Dinge loslassen. Wenn Sie neu im Team sind und jemand sagt, dass Sie die Code-Konvention nicht einhalten, können Sie nur auf seine Erfahrung zurückgreifen und vorschlagen, die Dokumentation zu aktualisieren, wenn sie irreführend geworden ist. Wenn dies zu Reibungsverlusten führt, müssen Sie sich an Ihren Chef wenden, da das Halten eines Standards auf Papier und eines anderen in der Praxis (insbesondere auf Geheiß einzelner Entwickler) nicht übereinstimmt und untergräbt.

Ich würde mich jedoch viel eher auf die Bedrohung konzentrieren, die auf Sie gerichtet ist. Wenn es mündlich geschehen wäre, hätten Sie zu diesem Zeitpunkt keine guten Beweise und Sie hätten zu diesem Zeitpunkt keine gute Möglichkeit, zu handeln, aber ich würde in Zukunft sehr vorsichtig mit ihm umgehen und versuchen, alles, was er sagt, schriftlich zu erhalten, z. Interagiere so oft wie möglich per E-Mail. Wenn er Sie erneut schriftlich bedroht, können Sie mit Ihrem Chef darüber sprechen. Nach den Geräuschen der Dinge ist sein Ego so zerbrechlich, dass Sie früher oder später wieder auf Probleme mit ihm stoßen werden.

Wo Sie möglicherweise auf Probleme stoßen, ist, dass Sie die Laie nicht kennen von dem Land. Wenn dieser Typ wirklich so schlecht ist, wie er scheint, ist es möglich, dass große Teile des Codes von ihm geschrieben wurden und von niemandem außer ihm nicht mehr gewartet werden können. Als solcher hat er sich effektiv unerwünscht gemacht, da das Unternehmen es sich nicht leisten kann, ihn zu verlieren, was sein schlechtes Verhalten ermöglicht hat. Dies kann kurz- bis mittelfristig gut für die Arbeitsplatzsicherheit sein, langfristig ist es jedoch entartet, kontraproduktiv und kann Ihren Ruf ruinieren. Streben Sie nicht danach.

Achten Sie in diesem Sinne darauf, dass Sie das Unternehmen nicht in die Lage versetzen, Entscheidungen zu treffen, da die Interessen des Unternehmens an erster Stelle stehen. Behandeln Sie Ihren aktuellen Job als Lernerfahrung im Umgang mit schwierigen Menschen. Verbringen Sie Zeit mit Ihren Kollegen und finden Sie heraus, wie sie mit diesem Kerl umgehen, und verpassen Sie nicht die Gelegenheit, auch andere Dinge von ihnen zu lernen. Behalten Sie in der Zwischenzeit andere Möglichkeiten im Auge und seien Sie bereit, auf Ihren Füßen zu landen, falls er die Schlagkraft hat und Sie wegen eines anderen wahrgenommenen Verstoßes rauswirft.

Die Antwort darauf hängt stark von der allgemeinen Herangehensweise an die "Prozesseinhaltung" innerhalb des Unternehmens ab, und Sie sollten bereits ein Gefühl dafür haben.

Ich habe in einem Unternehmen gearbeitet, das, auf Papier, ISO9001 zertifiziert, aber der CEO nervte uns immer mit Angebotsanfragen, die durch schnelle und unvollständige Telefonanrufe gestellt wurden, obwohl wir ein Anfrageformular hatten, in dem alle Informationen gesammelt werden konnten. Sie vermuten wahrscheinlich, dass in diesem Fall die Durchsetzung von Standards ein verlorener Kampf war.

Sie haben zwei Alternativen:

1. Das Unternehmen hat eine Kultur der Prozesseinhaltung : Sie haben Recht, die Kodierungskonvention des Unternehmens zu befolgen, und wenn die Sache eskaliert, stellen Sie einfach klar, dass Sie den Standard befolgt haben.
2. Die Einhaltung von Prozessen erfolgt nur auf dem Papier : Vergessen Sie die Handbuch, und folgen Sie dem "Hinweis" dieses Senioren.
ol>

"Die Codekonvention besagt eindeutig, dass ich Code ändern kann, um ihn im Sinne der Codekonvention zu erstellen. Die Konvention wurde von seinem direkten Manager geschrieben."

Ich kann nicht anders, als zu glauben, dass dies der Fall ist Eine schreckliche Anweisung. Auf jeden Fall ein Ticket generieren, um einen bestimmten Codeabschnitt zu "verbessern" oder auf den Standard zu bringen, aber "ändern, wenn Sie nicht mögen, wie er aussieht" ist ein Rezept für eine Katastrophe. Wie steuern Sie diese Änderungen, wenn sie als Teil eines anderen Fixes vorgenommen werden? Wie testen Sie die Änderungen?

Meines Erachtens ist Ihr Problem mit dem Peer-Code die formale Code-Konvention, von der Sie ein anderes Verständnis haben als der Senior.

Es gibt viele Tools, die den Code automatisch nach einer Reihe konfigurierbarer Regeln für Sie formatieren. Sie lassen nicht viel Raum für die Interpretation der Konventionen.

In einer regelmäßigen Teambesprechung (vorzugsweise eine Scrum-Retrospektive) beziehen Sie sich möglicherweise auf Ihre Diskussion mit dem Senior und darauf, dass Sie mit der Situation unzufrieden sind, und schlagen dann vor, dass Ihr Team (oder zumindest Sie) startet Verwenden Sie einen solchen automatischen Formatierer und benennen Sie den Senior, um den Regelsatz zu konfigurieren.

Wenn Sie das nächste Mal den Seniorencode ändern (um einen Fehler zu beheben), erfolgt die Neuformatierung durch ein von ihm konfiguriertes Tool. Ich bin gespannt, wie er dir dann die Schuld geben kann ...