Ein anderer Programmierer schreibt meinen Code ständig neu [geschlossen]

Ich glaube nicht, dass du überhaupt etwas tun musst. Aber wenn ich in dieser Situation wäre, würde ich eine Richtlinienänderung vorschlagen, dass für alle Umschreibungen oder Neugestaltungen nach Möglichkeit der ursprüngliche Autor des Codes vor Beginn der Arbeit zu dem Problem konsultiert werden sollte und ein obligatorischer Prüfer des fertigen Codes.

Die normale Begründung für diese Richtlinie ist, dass der ursprüngliche Autor ein besseres Verständnis der Anforderungen hat, die der Code erfüllen muss, und der dahinter stehenden Entwurfsgründe. Aber es hilft auch, Menschen daran zu hindern, Dinge zu reparieren, die nicht kaputt sind.

Wenn Sie eine solche Richtlinie durchgesetzt bekommen, sollten Sie vor der nächsten solchen "Neugestaltung" konsultiert werden. Es ist völlig vernünftig, so etwas mit dem Argument abzulehnen, dass die Vorteile nicht die Kosten und Risiken rechtfertigen, die mit der Änderung von Code verbunden sind, von dem bekannt ist, dass er funktioniert.

Aber wenn dies nicht funktioniert, machen Sie sich keine Sorgen. Wenn sein Vorgesetzter denkt, dass das, was er tut, seine Zeit wert ist, dann lassen Sie ihn damit weitermachen. Es ist nicht Ihre Aufgabe, perfekten Code zu schreiben, sondern effizient wartbaren, dokumentierten Code zu schreiben, der die Anforderungen und Programmierstandards erfüllt. Wenn Sie Ihre Behauptung verteidigen können, dass Sie das tun, dann lassen Sie ihn tun, was er will.

Das Umschreiben des Codes anderer Leute ist normal. Es passiert ständig; Wenn die Einheiten-/Integrationstests weiterhin bestanden werden und der Code überprüft wird, lassen Sie ihn einfach los.

Aber das Umschreiben von Code, der nicht kaputt ist (er tut, was er tun soll und ausreichend effizient ist und dessen Stil die Entwicklung anderer Codeteile nicht beeinflusst), ist nicht in Ordnung. Dies ist eine Verschwendung von Zeit und Ressourcen.

Die Frage ist nun, wie sich diese Zeit- und Ressourcenverschwendung auf Sie auswirkt. Wenn Sie der Manager des Teams sind, wird die Produktivität Ihres Teams beeinträchtigt, und das sollte Sie stören.

Wenn dies ein Teamkollege ist, betrifft es Sie nicht direkt, also lohnt es sich nicht, es anzusprechen. Aber es wirkt sich auf das Team als Ganzes aus und die Fähigkeit des Teams, Dinge umzusetzen, kann beeinträchtigt werden, und dies könnte im Nachhinein angesprochen werden. Aber es sollte so zur Sprache gebracht werden, dass es keine Arbeit an aktuellen vorrangigen Aufgaben leistet.

Trennen Sie neue Funktionen vom Umschreiben des Codes.

Machen Sie deutlich, dass bei neuem oder geändertem Code keine Routinen neu geschrieben werden sollten, nur weil der Entwickler Ineffizienzen sieht. Akzeptiere, dass du derjenige bist, der hier die Richtung vorgibt. Geben Sie diese Richtung vor und bleiben Sie dabei. Wenn Effizienzsteigerungen beobachtet werden, stellen Sie sicher, dass die Auswirkungen auf die Kunden identifiziert werden. Manchmal liegt dies an langfristigen Qualitäts- und Infrastrukturproblemen.

Zeigen Sie gleichzeitig, dass Ihnen Quality Code am Herzen liegt. Identifizieren und ermutigen Sie diesen Entwickler, diese Bereiche zu identifizieren und Tickets für das Refactoring einzugeben. Planen Sie etwa alle 4-6 Wochen eine Refactoring-Woche ein und führen Sie das Refactoring nur während dieser Zeit durch.

Die Absicht ist:

• Prioritäten setzen
• Qualität fördern
• Entwicklungsaktivitäten mit den Unternehmenszielen in Beziehung setzen

Letztendlich ist dies kein Bereich, der feste Regeln haben wird. Manchmal sollte ein Refactoring sofort durchgeführt werden, da es sich um eine grundlegende Arbeit handelt. Manchmal sollte ein Refactoring niemals durchgeführt werden, da es kurz- oder langfristig viel Arbeit für wenig Nutzen für das Unternehmen bedeutet. Das Unternehmen verdient Geld und zahlt Gehälter basierend auf seinen Prioritäten. Es sollte derjenige sein, der die Prioritäten setzt. Wenn ein Entwickler ein Unternehmen auf andere Werte gründen möchte, kann er woanders arbeiten, sein eigenes Unternehmen gründen oder versuchen, sein aktuelles Unternehmen zu überzeugen. Sie müssen aber erst überzeugen, nicht erst handeln und danach überzeugen oder rechtfertigen.

Der Code wird nach dem Umschreiben viel ausgefeilter, mit mehreren Indirektionsebenen und eigenen "besseren" Implementierungen von Funktionen, die von den Standardbibliotheken bereitgestellt werden

Ich bin mir nicht 100 % sicher, was Sie oben meinen - aber könnte dies eine Gelegenheit für Sie sein, zu lernen, wie Sie die Standardbibliotheken besser oder effizienter nutzen können?

Besteht die Möglichkeit, dass sein Code besser ist und sich der Aufwand, Ihren Code neu zu schreiben, lohnt? Wenn ja, würde ich hoffen, dass sie Sie in die Codeüberprüfung aufnehmen, damit Sie lernen können, es besser zu machen.

Selbst wenn dieser Typ falsch ist, ist er vielleicht nicht völlig falsch - öffnen Sie Ihren Geist und schauen Sie noch einmal nach, stellen Sie sicher, dass Sie keine Lerngelegenheit verpassen.

Der Mitarbeiter kann immer Entwickler in seiner Nähe finden, um sie zu diskutieren und zu genehmigen.

Dies deutet darauf hin, dass es eine zu starke Vereinfachung ist, dass es ein Problem mit dem Kollegen gibt. Ich würde vorschlagen, dass es besser ist, die Art und Weise zu ändern, wie das Team zusammenarbeitet.

• Vielleicht sollte ein Aspekt des Überprüfungs-/Genehmigungsprozesses geändert werden
• Oder das gesamte Team sollte auf die Gefahren des Overengineering geschult werden
• Schulung des Teams zur Priorisierung der Arbeit

Eine der möglichen Lösungen wäre die Eskalation an die Geschäftsführung

Vielleicht sollten Sie, aber mit einigen Lösungsvorschlägen, wie das Team geschult werden kann, um besser zusammenzuarbeiten und seine Fähigkeiten und Kenntnisse zu verbessern.

Das Training selbst: Ich kann mir vorstellen, dass Sie googeln können, aber sogar (wie es in meiner vorherigen Firma war) so einfach (und billig!) wie wöchentliche Mittagssitzungen abzuhalten, sich einige YouTube-Konferenzpräsentationen anzusehen, sie zu diskutieren und zu sehen, wie sich das Gesagte auf Sie bezieht Geschäft/Codebasis könnte hilfreich sein. Oder Ihre Kollegen könnten ermutigt werden, Präsentationen zu bestimmten Aspekten des Programmierens zu halten, kritisches Feedback anzunehmen usw. Vielleicht sogar gemeinsam Programmierbücher/Blogs oder wissenschaftliche Arbeiten zu lesen. Oder Gruppen-Refactoring-Sitzungen. Das Team selbst könnte wahrscheinlich mehr vorschlagen!

Ich kann mir vorstellen, dass es auch hilfreich wäre, eine Kultur der Ehrlichkeit und Selbstkritik zu fördern. Schwierig zu erreichen, aber mit gutem Beispiel voranzugehen ist oft ein guter Weg! "Ja, mein Code hier war etwas überarbeitet. Wie können wir ihn verbessern?"

Mein Verdacht ist, dass es viel produktiver (und auf lange Sicht billiger/besser für das Unternehmen!) ist, dies eher als Gelegenheit zu sehen, um mehr Lernen/Training/Zusammenhalt für das gesamte Team voranzutreiben, als zu versuchen, „mit einem Problemmitarbeiter fertig zu werden ".

Dies ist in erster Linie ein Problem des schlechten Managements.

Wird Ihr Team konventionell geführt, werden Ihnen und den anderen Teammitgliedern Aufgaben zugewiesen. Entweder wurde dieser andere Entwickler mit der Aufgabe betraut, Ihren Code umzuschreiben, oder nicht.

Wenn ja, klingt es so, als ob Ihr Manager knappe Ressourcen für etwas zuweist, das das Projekt nicht voranbringt und für das Unternehmen von geringem Wert ist. Wenn nicht, dann sollte der Manager fragen, was vor sich geht, das ein unentgeltliches Engagement für die Aufgaben anderer Entwickler erfordert. Ich nehme an, es ist auch möglich, dass Aufgaben in Ihrem Team einfach nicht zugewiesen werden - aber in diesem Fall scheint das Free-for-all nicht sehr gut zu funktionieren und sollte erneut überprüft werden.

Wenn Ihr Team versucht, agile Prinzipien und Praktiken anzuwenden, funktioniert es nicht. Zwei klar formulierte Agile-Prinzipien sind:

Funktionierende Software ist das primäre Maß für den Fortschritt.

und

Einfachheit – die Kunst, die Menge an nicht erledigter Arbeit zu maximieren – ist entscheidend.

Wenn es sich um ein Scrum-Team handelt, soll Ihr Team die Zuweisung von Stories innerhalb des Sprints selbst verwalten. Die Arbeit, die dieser Teamkollege neu schreibt: Stellt sie eine ganze Geschichte dar? „Helft“ er Ihnen, eine Geschichte zu verwirklichen, oder ist die Geschichte bereits fertig, wenn er mit dem Umschreiben beginnt? Hat Ihr Team eine gemeinsame „Definition of Done“ ? Und wenn Sie bei einem täglichen Standup-Meeting berichten, dass Sie eine bestimmte Geschichte abgeschlossen haben, dann sind Ihre Teamkollegen verpflichtet, diese Geschichte als erledigt zu behandeln ... oder Einspruch zu erheben. Der ganze Sinn eines täglichen Standups besteht darin, Probleme im Sprint schnell und direkt zu lösen.

Kurz gesagt, Doppelarbeit ist das Gegenteil eines agilen Werts, und Ihr Team muss herausfinden, wie es damit aufhören kann. Vielleicht in Ihrem nächsten Sprint-Retrospektiven-Meeting.

Es besteht auch die Möglichkeit, die Ihre Analyse auf die eine oder andere Weise nicht angesprochen hat, dass Ihr Code eng genug mit der Arbeit der anderen Entwickler interagiert, dass er zumindest eine gewisse Rechtfertigung hat, Änderungen an ersterem vorzunehmen, um letztere zu berücksichtigen. (Angenommen, Sie hätten einige seltsame Aufrufkonventionen beibehalten oder einige Optionen nicht unterstützt, die er für notwendig hält.) Ihr Team muss möglicherweise daran arbeiten, die Spezifikationen klarer zu machen oder etwas mehr zu kommunizieren, bevor Sie Code schreiben.

Eine andere Sache, die, glaube ich, noch niemand erwähnt hat: Die Kosten hier sind nicht nur die Zeit und Mühe des anderen Entwicklers. Es gibt auch den Preis dafür, Ihre Motivation zu schwächen. Sie haben nicht gesagt, dass Sie entmutigt sind, aber das wäre eine übliche und verständliche Reaktion darauf, dass Ihre Arbeit regelmäßig gelöscht und entlassen wird. Menschen, die komplexe intellektuelle Arbeit leisten, sind nicht gut darin, wenn Sie sie weiterhin irrelevant machen.

Wenn ich diese Möglichkeiten jedoch in Betracht ziehe, kommen sie alle auf den Teammanager zurück. Diese Person muss sich der zusätzlichen Zeit und Mühe bewusst sein, die mit doppelter Arbeit verbunden sind. Entweder sind sie sich dessen bewusst und entscheiden sich dafür, das Problem zu ignorieren; oder sie sind sich dessen nicht bewusst, was darauf hindeutet, dass sie die Aufgaben, die sie Einzelpersonen zugewiesen haben, nicht ausführen, oder sie lassen zu, dass überhöhte Schätzungen der zugewiesenen Aufgaben als Zeitpuffer für diese nicht zugewiesenen Aufgaben dienen.