Wie übernehme ich die Verantwortung für meinen Code, wenn ein Kollege ohne Vorankündigung unnötige Verbesserungen vornimmt?


71

Einer meiner Teamkollegen ist ein Alleskönner in unserem IT-Shop und ich respektiere seine Einsicht.

Manchmal überprüft er jedoch meinen Code (er ist der zweithäufigste Befehlshaber unseres Teamleiters, das ist zu erwarten), ohne einen Hinweis zu haben. Manchmal überprüft er meine Änderungen, bevor sie das Endziel erreichen, und nimmt sofort Änderungen vor ... und hat sogar meine Arbeit einmal gebrochen.

In anderen Fällen hat er unnötige Verbesserungen an einem Teil meines Codes vorgenommen, der mindestens drei Monate alt ist.

Das ärgert mich aus ein paar Gründen:

  1. Ich habe nicht immer die Möglichkeit, meine Fehler zu beheben
  2. Er hat sich nicht die Zeit genommen, mich zu fragen, was ich erreichen wollte, wenn er verwirrt ist, was sich auf seine Tests oder Änderungen auswirken könnte
  3. Ich denke nicht immer, dass sein Code lesbar ist
  4. Abgabetermine sind kein Problem und seine aktuelle Arbeitsbelastung erfordert in meinen Projekten keine weitere Arbeit als die Überprüfung meiner Codeänderungen.

Wie auch immer, ich habe ihm in der Vergangenheit geraten, mich auf dem Laufenden zu halten, wenn er etwas in meiner Arbeit sieht, das er ändern möchte, damit ich den Besitz meines Codes übernehmen kann (vielleicht hätte ich "Mängel" sagen sollen), und er hat nicht reagiert .

Ich befürchte, dass ich aggressiv werde, wenn ich ihn auffordere, mir seine Änderungen zu erklären.

Er ist nur eine ruhige Person, die für sich bleibt, aber seine Handlungen gehen weiter. Ich möchte ihn nicht davon abhalten, Codeänderungen vorzunehmen (anders als ich es könnte), weil wir ein Team sind - aber ich möchte meinen Teil dazu beitragen, unserem Team zu helfen.

Klarstellungen hinzugefügt:

  • Wir teilen uns 1 Entwicklungszweig. Ich warte nicht, bis alle meine Änderungen eine einzelne Aufgabe abgeschlossen haben, da ich das Risiko habe, bedeutende Arbeit zu verlieren. Deshalb stelle ich sicher, dass meine Änderungen erstellt werden und nichts kaputt geht.
  • Ich mache mir Sorgen, dass mein Teamkollege den Grund oder den Zweck seiner Änderungen nicht erklärt. Ich denke nicht, dass er meinen Segen brauchen sollte, aber wenn wir uns nicht einig sind, dachte ich, dass es am besten ist, die Vor- und Nachteile zu diskutieren und eine Entscheidung zu treffen, sobald wir beide verstehen, was los ist.
  • Ich habe dies noch nicht mit unserem Teamleiter besprochen, da ich es vorziehen würde, persönliche Meinungsverschiedenheiten zu lösen, ohne das Management einzubeziehen, es sei denn, dies ist erforderlich. Da mein Anliegen eher ein persönliches Problem als eine Bedrohung für unsere Arbeit zu sein schien, habe ich mich entschieden, den Teamleiter nicht zu belästigen. Ich arbeite an Ideen für Codeüberprüfungsprozesse, um die Vorteile besser organisierter Codeüberprüfungen zu fördern, ohne dass sich alles um mein Haustier dreht.

20
Verwenden Sie Git, CVS oder TFS für Ihr Code-Repo? Rollen Sie einfach seine Verpflichtungen zurück. Er wird es schließlich bekommen :)

6
In meiner Organisation sollten alle Codeänderungen eine Überprüfung durchlaufen, und es wird als fehlerhaft angesehen, eine Änderung einzuchecken, ohne in der Beschreibung der Änderungsliste zu vermerken, wer der Überprüfer war. Die Einführung dieses Prinzips in Ihrer Organisation könnte eine langfristige Lösung für das Problem sein, dass Mitarbeiter Änderungen an Code einchecken, die Sie ohne Überprüfung geschrieben haben.
Carolyn

13
Warum gibt es in einer gemeinsam genutzten Zweigstelle noch nicht abgeschlossene Änderungen? Das ist eine schlechte Idee, und das nicht nur aus dem Grund, auf den Sie gestoßen sind.
Hyde

15
Dies hängt natürlich davon ab, welches VCS Sie verwenden, aber das könnte ein Grund sein, sich mit der Verwendung von Zweigen zu befassen. Mit der persönlichen Verzweigung ist es IMO großartig, wenn Sie ohne Bedenken Daten festschreiben (und mit DVCS weitergeben) und nur dann zusammenführen können, wenn dies mit einem Teil erledigt ist, oder wenn dies nur teilweise erforderlich ist (ein gutes DVCS macht dies ziemlich einfach). Funktioniert auch hervorragend mit Codeüberprüfung, da dies auf natürliche Weise möglich ist und Probleme vor dem Zusammenführen behoben werden.
Hyde

4
@Jesslyn - Ist Ihr Teamleiter überhaupt besorgt, dass Ihr Teamkollege Zeit damit verbringt, unnötige Verbesserungen am alten Code vorzunehmen? Zumindest scheint es ineffizient für Ihren Teamkollegen zu sein, unnötige Änderungen vorzunehmen, anstatt Aufgaben mit höherer Priorität zu erledigen. Wenn Ihr Teamkollege lieber Zeit damit verbringt, Ihren Code für Sie zu "reparieren", als Sie dazu zu befähigen, dies selbst zu tun, scheint dies ebenfalls ineffizient zu sein. Haben Sie eines dieser Anliegen mit Ihrem Teamleiter besprochen?
Cliff

Antworten:


81

Ich denke, die meisten Entwickler befinden sich irgendwann in dieser Position, und ich hoffe, dass jeder Entwickler, der sich schikaniert gefühlt hat, erkennt, wie frustrierend es sein wird, wenn er oder sie zum Senior wird und sich gezwungen fühlt, von Junioren geschriebenen Code zu bereinigen.

Das Vermeiden von Konflikten in dieser Situation hat für mich zwei Gründe:

  1. Höflichkeit . Wenn Sie mit jemandem über seinen Code sprechen, kann ein Entwickler erkennen, dass Sie interessiert sind, und Sie können als erwachsene Fachleute darüber diskutieren.

  2. Vergessen Sie "Code Ownership" - das Team besitzt den Code . Andere Leute, die Änderungen vornehmen wollen, sind eine gute Sache. Wenn ein älterer Entwickler Änderungen vornimmt, die "unleserlich" oder noch schlimmer sind, setzen Sie sie zurück. Sie müssen nicht aggressiv sein. Lassen Sie einen Redakteur einfach wissen, dass seine / ihre Änderungen nicht funktioniert haben, und Sie sind mehr als glücklich, über Ihre Umkehrung zu diskutieren.

Denken Sie daran, dass der Besitz von Code im Team großartig ist und sich in beide Richtungen auswirkt. Wenn Sie etwas sehen, das im Code einer anderen Person keinen Sinn ergibt, beheben Sie es. Übermäßig besitzergreifend und unzureichend kommunikativ zu sein, ist ein todsicherer Weg, eine giftige Entwicklungsumgebung zu schaffen.


4
Ich denke, das kommt auf Punkt 1 an - sprechen Sie mit ihm. Die Tatsache zu zählen, dass sich der Code gegenüber dem ursprünglichen Entwickler ändert, ist ein schreckliches Management (ich sage nicht, dass es nicht passiert), und ich würde argumentieren, dass Sie eine Petition für bessere Metriken einreichen müssen. Überqueren Sie diese Brücke, wenn es passiert.
Michael

2
Ich denke, darauf sollten wir uns alle konzentrieren - im Allgemeinen sind Ihre Teamkollegen nicht bestrebt, Sie schlecht aussehen zu lassen -, nehmen Sie sich keine Zeit für Analysen, werden Sie einfach besser und ein wertvolleres Mitglied des Teams (ich weiß, das ist einfacher gesagt) als getan, obwohl!)
Michael

7
@Jesslyn, Wenn er es dir antut, tut er es aller Wahrscheinlichkeit nach allen. Ich bezweifle, dass jemand das gegen Sie zählt. (Wenn er es nicht allen
antut

3
@tgkprog: (1) Natürlich ist es sehr wichtig, Feedback von anderen zu erhalten, und ich habe ein paar Dinge gelernt, indem ich mir den Code anderer angesehen habe. (2) Wenn Sie voneinander lernen möchten, sollten Sie eine Änderung vorschlagen und diese gemeinsam diskutieren . Nur zufällige Dinge zu ändern, weil Sie denken, dass der Code nach der Änderung besser ist, ist nicht der richtige Ansatz. Es gibt bessere Ansätze wie Codeüberprüfungen mit Überprüfungstools.
Giorgio

2
Ja , ich dachte an Zeiten , in denen ich andere Code vor einer toten Linie um 11 Uhr festgelegt haben , aber selbst dann eine E - Mail schicken würde ein Team , damit sie es überprüfen, einschließlich unserer QA ....
tgkprog

86

Sie und die meisten Antwortenden betrachten dies als ein Kommunikationsproblem zwischen zwei Kollegen, aber ich denke nicht, dass dies wirklich so ist. Was Sie beschreiben, klingt eher nach einem fürchterlich kaputten Code-Überprüfungsprozess als nach irgendetwas anderem.

Zunächst erwähnen Sie, dass Ihr Kollege als Zweiter das Kommando innehat und dass er Ihren Code überprüfen wird. Das ist einfach falsch. Peer-Code-Reviews sind per Definition nicht hierarchisch und es geht sicherlich nicht nur darum, Fehler zu finden. Sie können auch Lernerfahrungen (für alle Beteiligten) bereitstellen, eine Möglichkeit zur sozialen Interaktion bieten und sich als wertvolles Werkzeug für den Aufbau von kollektivem Code-Besitz erweisen. Sie sollten auch von Zeit zu Zeit seinen Code überprüfen, von ihm lernen und ihn korrigieren, wenn er sich irrt (niemand macht es jedes Mal richtig ).

Außerdem erwähnen Sie, dass Ihr Kollege Änderungen sofort vornimmt. Das ist auch falsch, aber du weißt es natürlich schon; Du hättest diese Frage nicht gestellt, wenn sein Gung Ho-Ansatz kein Problem gewesen wäre. Ich denke jedoch, Sie suchen nach einer Lösung am falschen Ort. Um ganz ehrlich zu sein, erinnert mich Ihr Kollege ein bisschen an ... mich, und was bei mir in ähnlichen Situationen funktioniert hat, war ein gut definierter und solider Überprüfungsprozess und eine Reihe großartiger Tools. Sie möchten Ihren Kollegen nicht wirklich davon abhalten, Ihren Code zu überprüfen und ihn zu bitten, anzuhalten und mit Ihnen zu sprechen, bevor jede kleine Änderung tatsächlich nicht funktioniert. Es könnte eine Weile dauern, aber er wird bald einen Punkt erreichen, an dem es einfach zu nervig wird und Sie sind wieder da, wo Sie begonnen haben, oder schlimmer: Er hört einfach auf, Ihren Code zu überprüfen.

Ein Schlüssel zu einer Lösung könnte hier ein Peer-Code-Überprüfungstool sein. Ich vermeide in der Regel Produktempfehlungen, aber für Code-Reviews Atlassian's Crucibleist wirklich ein Lebensretter. Was es tut, mag sehr einfach erscheinen, und es ist es, aber das bedeutet nicht, dass es nicht erstaunlich großartig ist. Es wird an Ihr Repository angeschlossen und bietet Ihnen die Möglichkeit, einzelne Änderungssätze, Dateien oder Dateigruppen zu überprüfen. Sie dürfen keinen Code ändern, sondern Sie kommentieren alles, was sich nicht richtig anfühlt. Und wenn Sie unbedingt den Code einer anderen Person ändern müssen, können Sie einfach einen Kommentar mit dem Änderungssatz hinterlassen, in dem Ihre Änderungen erläutert werden. Das Einführungsvideo auf der Produktseite von Crucible ist sehenswert, wenn Sie weitere Details wünschen. Die Preisgestaltung von Crucible ist nicht jedermanns Sache, aber es gibt zahlreiche frei verfügbare Peer-Review-Tools. Eines, mit dem ich zusammengearbeitet habe und das mir gefallen hat, ist Review Board. Ich bin sicher, dass Sie mit einer einfachen Google-Suche viele andere finden werden.

Welches Tool Sie auch wählen, es wird Ihren Prozess komplett verändern. Sie müssen nicht anhalten, Ihren Stuhl verlassen, die andere Person unterbrechen und die Änderungen besprechen. Alles, was Sie tun müssen, ist wöchentlich eine Pause einzulegen und die Kommentare durchzugehen (einmal pro Woche ist nur ein Vorschlag. Sie kennen Ihren Zeitplan und Ihren Tagesablauf besser als ich). Noch wichtiger ist, dass die wichtigsten Bewertungen irgendwo in einer Datenbank gespeichert sind und Sie sie jederzeit abrufen können. Es sind keine kurzlebigen Diskussionen um den Wasserkühler. Mein bevorzugter Anwendungsfall für alte Reviews ist die Einführung eines neuen Teammitglieds in unsere Codebasis. Es ist immer schön, wenn ich jemanden durch die Codebasis führen kann, der darauf hinweist, wo genau wir feststeckten, wo wir unterschiedliche Meinungen hatten usw.

Weiter erwähnen Sie, dass Sie den Code dieses Kollegen nicht immer lesbar finden. Das lässt mich wissen, dass Sie keine gemeinsamen Codierungsstandards haben, und das ist eine schlechte Sache. Sie können dies wiederum als ein Personenproblem oder als ein Prozessproblem betrachten, und ich würde letzteres nachdrücklich empfehlen. Stellen Sie Ihr Team zusammen und setzen Sie so schnell wie möglich einen einheitlichen Codierungsstil und Standards ein. Es spielt keine Rolle, ob Sie eine Reihe von Standards gewählt haben, die in Ihrem Entwicklungs-Ökosystem üblich sind, oder ob Sie sich Ihre eigenen einfallen lassen. Was wirklich zählt, ist, dass Ihre Standards konsistent sind und dass Sie sich daran halten. Viele, viele Tools da draußen können Ihnen helfen, aber das ist eine ganz andere Diskussion. Nur um Ihnen den Einstieg zu erleichtern, Eine sehr einfache Sache ist es, einen Pre-Commit-Hook zu haben, der eine Art Formatierer für Ihren Code ausführt. Sie können Ihren Code weiter schreiben, wie Sie möchten, und das Tool ihn automatisch "reparieren" lassen, bevor es jemand anderes sieht.

Zuletzt erwähnen Sie in einem Kommentar, dass das Management nicht der Meinung ist, dass einzelne Entwicklungszweige notwendig sind. Es gibt einen Grund, warum wir sie "Entwicklungszweige" und nicht "Managementzweige" nennen. Ich werde hier anhalten, da es keinen Grund gibt, dass sich in meinem Kopf eine Schimpfe bildet, um rauszukommen.

Alles, was gesagt wurde, wissen Sie, dass ich nicht bezweifle, dass Ihr Kollege hier (ein bisschen) Schuld hat. Das ist nicht mein Punkt, mein Punkt ist, dass Ihr gesamter Entwicklungsprozess ebenfalls fehlerhaft ist, und das ist etwas, das einfacher zu beheben ist. Rüsten Sie sich mit den richtigen Werkzeugen aus, erkunden Sie die zahlreichen formellen und informellen Prozesse und wählen Sie diejenigen aus, die zu Ihrem Team passen. Bald wirst du einen Punkt erreichen, an dem du merkst, dass die meisten deiner "Menschenprobleme" nicht mehr existieren. Und bitte hören Sie niemandem zu (einschließlich sich selbst), der die Ausrede "Wir sind ein kleines Team, wir brauchen nicht all das" vorbringt. Ein Team von kompetenten Entwicklern kann die erforderlichen Tools in weniger als einer Woche einrichten, alles automatisieren, was automatisiert werden kann, und nie wieder zurückblicken.

PS. "Code-Besitz" ist ein nebulöser Begriff, der ständig diskutiert wird und für verschiedene Menschen unterschiedliche Bedeutungen hat. Sie finden eine brillante Sammlung der meisten unterschiedlichen (und manchmal gegensätzlichen) Meinungen zu C2 .


7
+1 und mehr, wenn ich könnte. Eine großartige Antwort, die die besten Möglichkeiten zur Verbesserung eines solchen Prozesses aufzeigt.
Waldfee

2
Ja, das OP benötigt ein Tool zur Codeüberprüfung. Auf diese Weise können Sie den Code gemeinsam überprüfen. Es ist nicht nur jemand, der den Code ändert, weil er Lust dazu hat. Wir haben gerade angefangen, smartbear.com/products/software-development/code-review bei der Arbeit zu verwenden
Juan Mendes

19

Was bringt Sie dazu , Verantwortung für "Ihren Code" zu übernehmen? Sind Sie allein dafür verantwortlich, dass bestimmte Funktionen weiterhin funktionieren? Sagte der Lead "Michael, ich möchte, dass du die Verantwortung übernimmst für ..."? Oder liegt es in Ihrer Verantwortung, dass der Leiter und der Rest des Teams jedes Mal zu Ihnen schauen, wenn bestimmte Funktionen beschädigt werden?

In jedem Fall benötigen Sie die Autorität über den Code, wenn Sie die Verantwortung haben. Wenn der andere Mitarbeiter das nächste Mal einseitige Änderungen vornimmt und der Lead zu Ihnen zurückkehrt, um diese zu beheben, sollten Sie sich an den Lead setzen und darum bitten, dass Ihre Autorität und Ihre Verantwortung in Einklang gebracht werden.


5
+1 Für den Hinweis auf eine wichtige Tatsache: Entweder gibt es Teambesitz und (1) alle sind verantwortlich (2) jeder kann den Code ändern, oder es gibt Einzelbesitz und (1) der Modulbesitzer ist verantwortlich (2) jede Änderung muss vom Modulinhaber genehmigt werden. Oft kommt es zu Verwirrung, wenn von einem Teammitglied erwartet wird, dass es für ein Modul verantwortlich ist, ein älteres Mitglied sich jedoch berechtigt fühlt, zufällige Änderungen am Code vorzunehmen. Mit anderen Worten, man muss die Situation "Verantwortung ohne Autorität" vermeiden.
Giorgio

4

Nicht, dass dies die ganze Situation lösen würde, aber Sie könnten versuchen, Ihrem Quellcode weitere Kommentare hinzuzufügen.

  1. Wenn der Code nicht vollständig ist, kann er als solcher gekennzeichnet werden.
  2. Wenn der Zweck eines Codeblocks nicht selbstdokumentierend ist, sollten Sie ihn dokumentieren.

Alles in allem versuchen Sie, Limonade zuzubereiten, anstatt Zeit mit Zitronen zu verschwenden. Wie Michael sagte, sind Teamkollegen im Allgemeinen nicht dazu da, dich schlecht aussehen zu lassen. Versuchen Sie, aus Ihren Fehlern zu lernen und sie auf zukünftige Überarbeitungen anzuwenden.

Wenn Sie glauben, dass seine Änderungen negative Auswirkungen haben, sprechen Sie dies bitte (diplomatisch) aus. Wenn ich es wäre, würde ich einfach fragen, warum bestimmte Änderungen vorgenommen wurden und sehen, ob Sie Ihre ursprünglichen Änderungen verteidigen können. Ihre älteren Mitarbeiter sind auch menschlich. Es ist durchaus möglich, dass er etwas verpasst hat und / oder keine negativen Auswirkungen bemerkt.


3
Junge, das könnte verwirrend werden. Stellen Sie sich vor, Sie fügen einen Kommentar hinzu, der besagt: "Dieser Code ist nicht vollständig", und vergessen dann, ihn zu entfernen, sobald Sie den Code vervollständigt haben.
Riwalk

1
@ Stargazer712, Verwirrender als unvollständiger Code in der Filiale?
user606723

Dafür sind Regalsets da. Checken Sie keinen unvollständigen Code ein.
Riwalk

2
Nein. Wenn Sie unvollständigen Code einchecken, für den ein Kommentar erforderlich ist, um ihn als solchen zu kennzeichnen, sind Sie bereits in der Hölle. Kommentare bringen Sie einfach in eine andere Ecke der Hölle.
Riwalk

1
Sie heißen TODOs, sie werden die ganze Zeit im Arbeitscode belassen
Juan Mendes

4

Jeder "besitzt implizit seinen eigenen Code", unabhängig von Politik, Legalistik oder Wirtschaft - es ist die "Natur der Dinge" - Sie fühlen sich auf natürliche Weise mit Ihrer eigenen Arbeit verbunden.

Wenn sich Ihr Mitarbeiter auf das von Ihnen beschriebene Verhalten einlässt und nicht reagiert, wenn Sie nach einem Heads-up fragen , ist dieser Mitarbeiter, gelinde gesagt, unhöflich und versucht möglicherweise, Sie zu untergraben (um das Schlimmste zu sagen). .) - klingt NICHT wie ein Teamplayer.

Ein guter Mitarbeiter würde Basis mit Ihnen berühren und das Problem mit Ihrem Code darauf hin , Sie - und lassen Sie es beheben / ändern oder entsprechend reagieren. Ich bin sehr dankbar , dass selbst wenn ich ein newbee war, meine Mentoren wiesen darauf hin , mich immer , was ich falsch macht, erklärt , warum und lassen (oder aus ) me fix it. Das hat mich zu einem besseren Programmierer gemacht und alle haben davon profitiert. Und das habe ich immer getan, wenn ich die Arbeit anderer überprüfte. Dann lernen Sie (oder wer auch immer) tatsächlich etwas von Ihrem „Alleskönner“, und der Code und das Team werden alle besser, einschließlich Ihres Lehrers: Lehren hilft zu verstehen.

Wenn es überhaupt möglich ist, würde ich die Angelegenheit privat mit dem Teamleiter besprechen . Basierend auf Ihrer Beschreibung der Situation wird ein guter Teamleiter Ihre Seite vertreten - ein schlechter nicht. Dies erfordert natürlich Vorsicht - das müssen Sie selbst beurteilen.


1
Abgesehen von der anfänglichen Aussage (es gibt Teams, die Teambesitz übernehmen, und andere Teams, die Einzelbesitz übernehmen), finde ich die Beobachtungen in dieser Antwort in Ordnung (+1 hierfür): Ich habe auch festgestellt, dass der gemeinsame Besitz von Code verwendet wird, um ein Team zu untergraben Position des Mitglieds im Team durch willkürliche Änderung seines Codes. Also verstehe ich die Abstimmungen nicht. Es wäre gut, wenn die Downvoter es erklären würden.
Giorgio

1
Ich denke, Mikeys Antwort ist eine gute Erklärung, wie ich ein Teamplayer bleiben kann. Vielleicht ist das zu menschenbezogen? Wie von Yannis vorgeschlagen, scheint der Entwicklungsprozess meines Teams das eigentliche Problem zu sein. Unabhängig davon bin ich gespannt, warum dies abgelehnt wurde.
Jesslyn

1
@ Jesslyn - Ich nehme an, ich wurde wegen meiner Aussage "Jeder hat implizit 'seinen eigenen Code'" abgelehnt. Dies ist eine philosophische Frage, keine politische Frage. :-)
Vector

1
@ Mikey: "Jeder hat implizit 'seinen eigenen Code'" Dies kann natürlich eine Frage der Debatte sein. Programmierer, die nicht selbstständig sind, unterzeichnen normalerweise einen Vertrag, der besagt, dass sie den Quellcode nicht besitzen. Abgesehen davon denke ich, dass der Autor des Codes derjenige ist, der den Code am besten versteht, und wenn jemand anders den Code ändert, dann verstehen weder der Autor noch der zweite Entwickler den Code wirklich zu 100%.
Giorgio

1
@Mikey: Shared Code Ownership versucht sicherzustellen, dass genügend Teammitglieder den Code gut genug verstehen (während niemand ihn wirklich gut versteht). Dies ist dem Besitz von individuellem Code vorzuziehen, bei dem jedes Modul (zumindest im Prinzip) von einem Programmierer vollständig verstanden wird, aber das Risiko besteht, dass dieses Wissen verloren geht, wenn dieser Programmierer beendet wird.
Giorgio

1

Wenn Sie Code schreiben, sollte ich ihn überprüfen.

Wenn ich Ihren Code während der Überprüfung ändere, ist der Code nicht mehr der Code, den ich überprüft habe, sondern der Code, den ich geändert habe. Daher muss es überprüft werden. Wahrscheinlich von dir.

Wenn ich Ihren neuen Code mit meinen Änderungen festschreibe, ohne dass jemand meine Änderungen überprüft, habe ich (1) eine nicht überprüfte Änderung und (2) die schlimmste Sünde begangen, wenn Codeüberprüfungen ernst genommen werden.


0

Ich denke, Sie gehen jetzt richtig damit um - aber es wird bald einen Wendepunkt geben, an dem Sie davon abgelenkt werden, in dem Sie möglicherweise überhaupt nicht glücklich sind, auf diese Weise zu programmieren.

Wenn ich Sie wäre, würde ich um ein schnelles Einzelgespräch mit dieser Person bitten und meinen PoV ruhig und doch fest erklären. Das Team-Eigentum an Code usw. ist in Ordnung, aber wenn Sie nicht jedem Entwickler genügend Platz einräumen, um seine Arbeit zu erledigen, Fehler zu machen und Verbesserungen vorzunehmen, werden Sie niemals guten Code erstellen. Dies kann eher früher als später ein Reibungsbereich sein.

(Es gibt eine völlig andere Antwort, wenn dies auf Workplace.stackexchange war. Es ist sehr einfach, herauszufinden, wie Code-Überprüfungen korrekt durchgeführt werden. Es ist sehr viel schwieriger, Ihren Kollegen davon zu überzeugen, sich daran zu halten.)

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.