Stimmen Sie der Antwort von @PeteCon zu.
Möglicherweise wechseln Sie in einen Verteidigungsmodus, da dies Ihr Code ist und in gewisser Weise Ihre Fähigkeiten widerspiegelt. Sie sagen, es gibt keine Rücksicht auf die Einschränkungen, mit denen Sie zum Zeitpunkt des Schreibens konfrontiert waren, aber das spielt keine Rolle. Schlechter Code ist schlechter Code. Wenn Sie etwas Funktionales erstellt haben, das jedoch nicht gewartet werden kann, müssen Sie ein Refactoring durchführen. Dies bedeutet nicht, dass das Herausgeben von etwas, das in kurzer Zeit funktioniert, kein Erfolg war.
Wie in der anderen Antwort erwähnt, müssen Sie die Vollzeitcodierung beenden und in die Verwaltung von Ressourcen übergehen. Ich bin auch nicht der Meinung, dass Ihre Entwickler an streng getrennten Teilen Ihrer Codebasis arbeiten - das ist es nicht! Wenn Sie Dinge wie Codeüberprüfungen effektiv übernehmen möchten, bei denen Entwickler beginnen können, die Zusammenführungsanforderungen der anderen zu überprüfen, sollten sie mit der Codebasis vertraut sein, die sie überprüfen. Außerdem erstellen Sie Wissensinseln, und wenn einer Ihrer Entwickler schließlich abreist, wird niemand verstehen, wie ihre Implementierungen funktionieren, da niemand mit seinem Teil der Codebasis gearbeitet hat und niemand die Qualität, Lesbarkeit und Dokumentation seines Codes sichergestellt hat via review.
Ich möchte eine Erfahrung teilen, weil sie Ihrer Geschichte sehr ähnlich klingt.
Die Geschichte der technischen Schulden
Damals bin ich einem Tech-Startup beigetreten. Es war mein zweiter Teilzeit-IT-Job, ich besuchte zu dieser Zeit noch die Universität. Das Team war großartig und ich mochte meine Aufgaben, aber es gab einige organisatorische Probleme.
Der leitende Entwickler war eine der größten und erfahrensten Personen, mit denen ich je gearbeitet habe. Sehr kompetent, sehr kompetent. Ihre Projekte waren auch ihr Baby. Ich vermute, sie hätten eine viel bessere Position mit einem viel höheren Gehalt einnehmen können, aber sie haben ihr Projekt geliebt und bleiben meines Wissens bis heute dort. Es wurde auch mit erstaunlicher Geschwindigkeit abgepumpt, schneller als ich es hätte tun können, aber es war mit einer Menge technischer Schulden verbunden.
Im Laufe der Zeit schlossen sich mehr Studenten und Nicht-Studenten den Entwickler-Reihen an, aber der Vorsprung blieb bestehen Arbeiten an der Codebasis, weil sie das gerne gemacht haben und ich verstehe das. Aber mit immer mehr Projekten fingen sie gerade an zu brennen. Später und später abends, um dies zu beenden, um dies zu beenden, um Server am Wochenende, im Urlaub, während des Krankenstands usw. zu codieren und zu warten.
In der Zwischenzeit gab es in den Unternehmensrichtlinien keine Überprüfungs- oder Testprotokolle . Einige Entwickler selbst haben den Lead um weniger Codierung und mehr Verwaltung gebeten, weil wir eine korrekte Versionsstruktur, eine ordnungsgemäße Repository-Organisation usw. brauchten, aber das kam einfach nicht zustande. Sie versprachen es uns wirklich, waren aber immer zu überladen mit der Arbeit, um DevOps zu machen.
Und so entwickelten sich zwei Dinge. Eine Sache waren Inseln. Ich habe mein Projekt, das eine große Einnahmequelle für das Unternehmen darstellte, als Student alleine gepflegt. Ich kannte alle geheimen Pfade, alle Code-Komplikationen, aber es blieb nicht genug Zeit, um alles zu tun, was gefragt wurde. Ausgepumpte Funktionen, versucht, eine Organisation im Repository zu finden, Kundenunterstützung zu leisten und weiterhin Feuer zu löschen. Die zweite Sache - unsere Codebasis hat sich verschlechtert. Niemand hat meinen Code überprüft, niemand konnte es irgendwann, es gab keine Zeit für Dokumentation und immer Ad-hoc-Patchwork.
Dies galt auch für andere Kollegen.
Daher verlangsamte sich die Entwicklung von w.r.t. -Funktionen bei allen außer den neuesten Projekten immer mehr, da immer mehr technische Schulden ihren Tribut forderten und wir unter ständigem Druck des Managements standen. Psychologischer Druck. Ich habe einmal einen Kollegen im Badezimmer beim Weinen erwischt, ein bisschen mit ihm gesprochen, festgestellt, dass ich meine Familie und meinen Partner seit fast einem Jahr entlastet habe - und beschlossen, dass es Zeit ist zu gehen.
Bis zum heutigen Tag schäme ich mich, diese Codebasis in einem so chaotischen Zustand zurückzulassen, weil ich viel daran gearbeitet habe, viel davon habe ich eingegeben. Aber wenn Sie jemals nur Patchwork machen, schnelles und schmutziges Zeug und so weiter , dann wird Ihr Code ein irredeemabe Chaos. Als ich aufhörte, gingen auch ein paar andere Leute. Noch zwei Inseln. Niemand war jemals mit ihren Codebasen vertraut, außer dem bis zu einem gewissen Grad.
Der Abschluss dieser Geschichte - diese Projekte sind größtenteils tot. Das Unternehmen verdient immer noch Geld mit ihnen, aber es gab keine weitere Entwicklung, außer für einige Dinge, die sich möglicherweise geändert haben. Die Stellen blieben vakant, neu eingestellte Entwickler waren offenbar nicht in der Lage, die jeweiligen Codebasen aufrechtzuerhalten.
Jetzt arbeite ich in einem Unternehmen mit ordnungsgemäßen Codeüberprüfungen, Tests, automatisierten Pipelines und Prozessen. Es ist so gut. Sicher, wir haben unsere Spezialitäten in der Codebasis, aber es gibt praktisch überhaupt kein Inselwissen, außerdem gibt es Codeüberprüfungen, sodass kein Code jemals den Hauptzweig erreicht, der von niemand anderem gesehen wurde. Meine geistige Gesundheit an meinem Arbeitsplatz hat sich ebenfalls verbessert, und meine Fähigkeiten sind jetzt auch viel schärfer.
Ich verstehe, Kritik an Ihrer Arbeit ist emotional schwer zu behandeln, aber Sie Sollte Kritik eine gute Sache sein, bedeutet dies, dass Ihre Entwickler möglicherweise die Codebasis verbessern, weil sie Dinge sehen, die anders sein könnten. Erstellen Sie keine Codebasisinseln, da Sie irgendwann Menschen verlieren und nicht versuchen, alles selbst zu reparieren. Sie arbeiten sich selbst auf der Intensivstation.