Sollte ich meinen Job kündigen, wenn ich eine schlechte Codebasis mit nicht so guter Unterstützung von den ursprünglichen Entwicklern übernehme?

Viel Legacy - Code nervt. Auch wenn der Code damals nach Best Practices entwickelt wurde, sind Best Practices vor zehn Jahren sehr oft ganz anders als Best Practices heute. Aber mehr als das, da Entwickler kommen und gehen, werden nicht alle Entwickler an der ursprünglichen Vision festhalten, die der ursprüngliche Entwickler hatte. Selbst wenn sie in der Lage sind, diese Vision zu verstehen, möchten sie sie möglicherweise nicht weiter vorantreiben. Einige Entwickler mögen sich darum kümmern, aber andere Entwickler können einfach schnell hässliche Hacks implementieren, um die Arbeit zu erledigen. Nach ein paar Jahren davon und Sie können eine wirklich hässliche Codebasis haben.

Mein Rat wäre, einfach zu versuchen, dabei zu bleiben. Wenn Sie jedes Mal vor einem Job davonlaufen, wenn Sie auf Mistcode stoßen, werden Sie vor jedem Job unter der Sonne davonlaufen. Nun, vielleicht mit Ausnahme von Green-Field-Startups. Wenn Sie sich jetzt daran gewöhnen, mit Mistcode zu arbeiten, können Ihre Erfahrungen Geschichten sein, die Sie später in Interviews teilen!

Es gibt eine Reihe von Arten von Programmiererjobs. Dies ist einer von ihnen.

"Legacy-Code unterstützen" ist ein großer Teil der Branche, mit unterschiedlichem Grad an Hässlichkeit. Wenn Sie entscheiden, dass Sie nicht damit einverstanden sind, in diesem Teil des Bereichs zu arbeiten, dann ja, können Sie gehen und sich einen anderen Job suchen, aber Sie sollten sich darüber im Klaren sein, dass Sie einen Großteil des möglichen Karriereraums ausschneiden. Wenn Sie mit Legacy-Code im Allgemeinen einverstanden sind, aber denken, dass dieser spezielle Legacy-Code einzigartig hässlich ist, und Sie sich nicht speziell mit diesem Zeug befassen möchten? Nun, du könntest recht haben. Darauf würde ich aber nicht unbedingt wetten.

Es hört sich so an, als müssten Sie im Laufe der Zeit am Refactoring arbeiten. Ihr Chef wird Ihnen wahrscheinlich in absehbarer Zeit keine Gelegenheit bieten, größere Refactoring-Vorgänge durchzuführen, aber er wird Sie nicht davon abhalten, den Code, den Sie berühren, zu verbessern. Sobald Sie herausgefunden haben, was ein Codeabschnitt tut, kommentieren Sie ihn. Wenn Sie einen Teil des Codes berühren und diese Wrapper "alle Fehler schlucken" sehen, überlegen Sie, wo Sie es sich leisten können, sie informativer zu gestalten. Selbst wenn Sie sie weiterhin in den Protokollen ausführen, können Sie den gesamten Stack-Trace dort ablegen. An diesem Punkt sollte es ohnehin relativ einfach sein, die benötigten Informationen zu erhalten. Wenn Sie die Dinge besser verstehen, arbeiten Sie daran, sich zu verbessern, wo Sie können.

Ist das in Bezug auf „Dinge pünktlich fertigstellen“ nur Ihre Wahrnehmung oder bekommen Sie irgendeine Art von Feedback von Ihren Chefs, dass sie Ihre Arbeit für inakzeptabel halten? Es stimmt, dass es länger dauert, mit Legacy-Code mit viel Code-Schuld zu arbeiten, besonders wenn Sie gerade erst anfangen. Es ist möglich, dass sie dies berücksichtigen und Sie nicht. Dies wird wahrscheinlich besser, wenn Sie ein tieferes Verständnis dafür bekommen, wie das System funktioniert (und es schaffen, einiges davon umzugestalten). So weit wie "Ihr Wachstum beeinflussen"? Nun... ja, aber nicht so, wie du denkst. Es hat keinen Einfluss darauf, ob Sie wachsen oder wie viel Sie wachsen. Es wird beeinflussen , wie Sie wachsen. Wie ich bereits sagte, ist die Verwaltung von Legacy-Code ein großer Teil der Branche. Zu lernen, wie man es gut macht, ist kein verschwendetes Wachstum.

Legacy-Code macht den größten Teil der Entwicklung auf dem Markt aus. Sie können selten neue Projekte mit modernsten Tools und Praktiken von Grund auf neu entwickeln.

Legacy-Code ist an sich nicht schlecht, aber es kommt immer noch so häufig vor, dass Sie lernen müssen, wie man in einer solchen Umgebung arbeitet.

Ich sage nicht, dass Sie es aufsaugen und dabei bleiben müssen, aber dass Sie Ihrem Arbeitsplatz eine Chance lassen müssen. Sie müssen lernen, wie man mit Legacy-Code umgeht (Sie können zum Beispiel „Effektives Arbeiten mit Legacy-Code“ lesen) und Sie müssen Ihren Kollegen und Vorgesetzten über die Kosten von schlechtem Code aufklären.

Wenn Sie Menschen bessere Praktiken beibringen und bewährte Praktiken und Tools an Ihrem Arbeitsplatz einführen können, gewinnen Sie wertvolle berufliche Fähigkeiten und Glaubwürdigkeit. Wenn sich die Situation jedoch nicht bessert und Sie darunter leiden, suchen Sie sich auf jeden Fall einen anderen Arbeitsplatz.

Ich würde weiter arbeiten. Geben Sie Ihr Bestes mit der Codebasis, so wie sie ist, Sie werden bald den Dreh raus haben, wie sie zusammenhängt.

Bereinigen Sie den Code, während Sie an Elementen arbeiten, so gut wie möglich in den Bereichen, in denen Sie arbeiten. Nach einer Weile sollten Sie in der Lage sein, etwas Zeit für umfassendere Arbeiten freizugeben.

Aber für den Moment, hochfahren und nach Bedarf anpassen. Betrachten Sie dies als eine Lernerfahrung.

Auch wenn Sie gegangen sind und einen anderen Job gefunden haben, ist die Wahrscheinlichkeit, dass Sie in einem Team landen, das eine fabelhaft organisierte Codebasis verwendet, minimal. Perfekter Code ist ein Ideal, aber es wird immer einen Kompromiss zwischen Perfektion und "erledigen" geben. Die meiste Zeit gewinnt "Get it done".

Wie andere sagten, gibt es jede Menge Mistcode da draußen, und viele von uns werden ihn am Ende warten.

(Es ist auch fair zu sagen, dass wir diejenigen sind, die ihn erstellen, unter Druck oder am Anfang unserer Karriere oder weil wir es nicht besser wissen. Nehmen Sie es nicht persönlich, wenn andere Ihnen solchen Code aufzwingen! )

Ihre Entscheidungen zu Beginn Ihrer Karriere sind jedoch von Bedeutung. Viel . Wenn Sie Ihre ersten paar Jobs mit der Wartung einiger Spaghetti-Code-Apps verbringen, wird es schwierig sein, Ihre feineren technischen Fähigkeiten zu entwickeln. Es wird schwierig sein, gutes Design zu lernen. Und schlechte Designs zu erkennen ist nicht dasselbe wie zu wissen, wie man gute entwirft.

Meiner Erfahrung nach wird dies Ihre späteren Karrierechancen verkümmern. Ich interviewe viele Software-Ingenieure und habe aus genau diesem Grund Bewertungen abgelehnt. Sie sind nett, freundlich und kennen grundlegende Programmierkenntnisse, aber nachdem sie jahrelang in einem schlechten Umfeld gearbeitet haben, scheinen sie nicht weiter zu sehen. Sie wissen nicht, wie man Probleme gut löst. Nachdem ihnen oft gesagt wurde, dass sich die Dinge nicht ändern können (oder sich ändern, aber langsam), verloren sie ihren Funken. Ihre Go-to-Engineering-Lösungen werden durch ihre (schlechten) Erfahrungen gefärbt sein.

Wenn einem frischgebackenen Absolventen feinere Fähigkeiten fehlen, sucht ein Personalchef nach der Fähigkeit zu lernen. Wenn jemandem mit 5 oder 10 Jahren Erfahrung diese Fähigkeiten fehlen, ist das ein großes Warnsignal. Warum haben sie es noch nicht gelernt? Werden sie jemals Sind sie trainierbar?

Wenn Sie zu Beginn Ihrer Karriere wählerisch in Bezug auf Ihre Jobs sind, werden Sie Ihre Auswahl einschränken. Nicht wählerisch zu sein, schränkt später auch Ihre Auswahl (und Ihr Gehalt) ein.

Worauf man bei diesem – oder anderen – Jobs achten sollte. Es kommt nicht so sehr auf die Technik an, sondern auf die Mentoren. Finden Sie einen Ort, an dem Sie wirklich von jemandem lernen können, und kleben Sie sich dann an ihn oder sie. Lernen Sie so viel wie möglich, bevor Sie zur nächsten Gelegenheit übergehen.

Sie schrieben:

Ich habe mit meinem Manager gesprochen, seine Antwort ist, dass ich diese Codebasis nach einiger Zeit umschreiben kann, aber ich liefere, was erwartet wird, bevor ich mit dem Umschreiben beginne, was wiederum auf den Punkt kommt, ich kann diesen Spaghetti-Code nicht herausfinden, wenn ich kann, würde ich es tun nicht einmal umschreiben müssen

Das klingt nach einem idealen Fall für ein schrittweises „Refaktorisieren“ der Codebasis.

Nutzen Sie bei der Erledigung Ihrer täglichen Aufgaben die Gelegenheit, die Codebasis zu „refaktorisieren“ (verbessern). Beginnen Sie beispielsweise damit, die Ausnahmebehandlung zu verbessern. Fügen Sie dann Kommentare hinzu. Verbessern Sie dann die Abfragebehandlung. Dann etwas anderes verbessern und so weiter.

Sprechen Sie mit Ihrem Vorgesetzten, teilen Sie ihm Ihre Ambitionen mit und mischen Sie die "Refaktorisierungs"-Arbeit mit Ihren täglichen Aufgaben. Überzeugen Sie sie davon, dass sich das Refactoring mittel- bis langfristig auszahlen wird, da eine bessere Codebasis einfacher zu bearbeiten ist, sowohl für Sie als auch für den nächsten Programmierer (wer das auch sein mag).

Mit der Zeit wird sich die Codebasis verbessern und eines Tages logisch organisiert und übersichtlich sein.

Als Programmierer haben wir alle von Zeit zu Zeit mit schlechtem Code zu tun. Seien Sie nicht verängstigt oder entmutigt – nehmen Sie dies als Herausforderung und Lernaktivität!

Also, willkommen in der eigentlichen Welt der Softwareentwicklung, nicht in der Welt, wie Sie sie gerne hätten. In der Welt, wie ich es mir wünsche, wäre jeder Code stark kommentiert, hätte richtige Testpläne, Designs, Anforderungsspezifikationen und viele andere Dinge.

Ich mache das seit 42 Jahren für Geld, ich bekomme immer noch nicht, was ich will.

Dies ist eher auf die Situation zugeschnitten, in der Sie sich befinden.

Bis Sie genug Erfahrung haben, was viel näher an 10 Jahren sein wird als dort, wo Sie sind, werden Sie nicht den professionellen Ruf haben, Organisationen zu Veränderungen zu bewegen. Was Sie jetzt, zu Beginn Ihrer Karriere, tun können, ist, diesen Ruf aufzubauen. Das bedeutet:

1. Hinterlassen Sie Code besser, als Sie ihn vorgefunden haben.
2. Codieren Sie idiomatisch in welcher Sprache auch immer. Machen Sie es nicht zu Ihrem persönlichen Stil, aber tun Sie es klar und lesbar und in der Sprache dieser Sprache.
3. Seien Sie wirklich vorsichtig, wenn Sie erfahreneren Entwicklern Vorträge halten. Wir alle wissen, dass wir von Managern, die damit aufhören müssen, gezwungen werden, Dinge zu tun, die wir nicht tun wollen.

Die Art von Problemen, die Sie beschreiben, sind etwas, das Jahre dauert, um es zu beheben. Zum einen gibt es eine Menge Legacy-Code, der im Laufe der Jahre verrottet ist. Zum anderen müssen Sie Ihre Kollegen von der Idee überzeugen.

Aber was Sie nicht tun können, wenn Sie jemals guten Code haben wollen, an dem Sie arbeiten können, ist aufhören. Denn am nächsten Ort ist es mehr oder weniger genauso schlimm.

Das Wichtigste zuerst: Nein, das ist kein normaler Vorgang. Ich habe über 15 Jahre als Softwareentwickler, in einem Startup (in Grossbritannien), in einer Regierungsbehörde (in Neuseeland), in einer grossen Forschungseinrichtung, in der Telekommunikation und in einem milliardenschweren Investmentinstitut (alle in der Schweiz) gearbeitet. Keiner von ihnen hatte auch nur annähernd diesen schlechten Code. Sicher, ich bin mehr als einmal auf all diese Probleme gestoßen (nicht auf den „90 %“-Teil, sondern alle separat), und insbesondere nicht-idiomatischer Code ist ziemlich häufig, aber eine Codebasis, die mit allen übersät ist, ist a Todesfalle.

Ein Manager, der sein Geld wert ist, wird wissen, dass Umschreibungen sehr riskant und ziemlich kostspielig sind, selbst wenn sie wirklich gut laufen. In einem Startup wäre es naiv zu erwarten, dass eine Neufassung irgendwo innerhalb des finanziellen Horizonts des Unternehmens liegt.

Ob Sie bleiben sollten, es gibt jede Menge Jobs, wo Sie die entsprechende Ausbildung bekommen, wo sich die Leute wirklich um Dinge wie Qualität und Sicherheit kümmern, wo Manager realistisch und ehrlich in Bezug auf Umschreibungen sind, wo Sie sich an Leute mit intimen Kenntnissen wenden können vorhandenes System für Hilfe, und, wenn auch nur ein bisschen Glück, alle oben genannten.

Mit einer alten Codebasis arbeiten zu müssen, ist an sich kein Problem. Jemand muss es tun. Genauso wie jemand jede Woche oder alle zwei Wochen den Müll der Leute einsammeln muss. Wenn es dir nicht gefällt, solltest du dir natürlich einen anderen Job suchen.

Das arbeitsplatzbezogene Problem kann sein, dass Ihre Arbeit nicht geschätzt wird. Es verursacht nur Kosten für das Unternehmen, keine neuen Einnahmen. Und wie Sie sagten, erzielen Sie pro Woche weniger Ergebnisse als in einer anderen Position. Aber es muss Ihrem Vorgesetzten und dem Management im Allgemeinen klar gemacht werden, dass Sie für die geleistete Arbeit bezahlt werden müssen, nicht dafür, wie viel Gewinn sie in die Taschen des Unternehmens einbringt. (Und wenn es nur Kosten verursacht, aber keine neuen Einnahmen, dann würde es wahrscheinlich großen Schaden anrichten, wenn diese Arbeit nicht getan würde, oder sie hätten Sie gar nicht erst eingestellt. Gewinne zu erzielen und Verluste zu vermeiden, ist dasselbe. Oder wir sollten die Feuerwehrleute in den Städten überall loswerden, da sie nie etwas Wertvolles produzieren. Normalerweise gibt es massive Verluste, wenn sie ihre Arbeit tun. Wenn sie ihre Arbeit nicht tun, gäbe es noch viel massivere Verluste,

Machen Sie Ihrem Chef also klar, dass (a) die Codebasis durcheinander gebracht und undokumentiert ist und dass jede Arbeit daran mehr Zeit in Anspruch nimmt als erwartet, und (b) Ihre Bezahlung gleich oder besser sein muss die der Leute, die die ausgefallenen Jobs machen.

Je nachdem, wie lange dieses Produkt voraussichtlich gewartet wird, vereinbaren Sie mit Ihrem Vorgesetzten, dass es Teil Ihrer Aufgabe ist, die Codebasis zu verbessern und zu dokumentieren.

Ein Teil davon liegt bei Ihnen. Wenn Sie sich für einen Job bewerben, insbesondere für einen Programmier- oder Ingenieurjob, sollten Sie einige der Fragen stellen:

• Welche Technologie wird verwendet? Wie groß und alt ist die Codebasis?
• Ist das eine Entwicklung auf der grünen Wiese?
• Gibt es eine gute Anzahl von Tests geschrieben?
• Welche Art von Automatisierung wird verwendet (CI/CD)?
• Was ist der Eincheck- und Zusammenführungsprozess, was verwenden Sie für die Quellcodeverwaltung?
• Welche Art von Tools verwenden Sie zur Unterstützung bei Entwicklung/Tests/Debugging?

Usw.

Stellen Sie diese Fragen unbedingt während des Vorstellungsgesprächs. Kein Unternehmen ist perfekt, aber es gibt viele Unternehmen/Codebasen da draußen, die einem die Seele rauben.

Wenn Sie unglücklich sind, halten Sie es einfach 6 Monate bis zu einem Jahr durch. Niemand hört gerne, dass ich meinen letzten Job gekündigt habe, weil die Codebasis schrecklich war. Sie könnten noch ein paar Dinge darüber lernen, was Sie NICHT tun sollten, und Sie können möglicherweise während Ihrer Amtszeit kleine Verbesserungen vornehmen, nach denen Ihr zukünftiger Mitarbeiter fragen wird.

Die Kernfrage lautet:

Versteht Ihr Management das Problem, erkennt es es an und beherrscht es seine eigenen Erwartungen in Bezug auf Effizienz und Qualität der Arbeit auf der Grundlage dieser Codebasis?

Wenn ja: Betrachten Sie dies als Chance.

Wenn nein: Laufen :)

Ich habe oft festgestellt, dass der beste Ansatz, diese Angelegenheiten dem Management zur Kenntnis zu bringen, darin besteht, sich nicht über die Komplexität des Codes zu beschweren oder darüber, wie schwierig es ist, dagegen zu entwickeln, sondern eine klare Beschreibung eines Problems zu bringen, das durch verursacht wird diese Struktur.

In Ihrem Fall, in dem viele Ausnahmen verschluckt werden, stellen Sie sich ein leicht erklärbares und reproduzierbares Problem, z. B.:

1. Client-Protokolle fügt dem Warenkorb ein Foo hinzu
2. Der Kunde checkt aus, aber der Checkout-Code schlägt bei der Zahlungsannahme stillschweigend fehl.
3. Wir versenden den Artikel trotzdem an den Kunden

Und das wird wahrscheinlich viel schneller ihre Aufmerksamkeit erregen. Es ist eine Frage des Rahmens:

„Ich habe ein Problem mit der Codebasis, die es sehr schwierig macht, diesen Code zu schreiben und zu warten, ohne Fehler einzuschleusen – kann ich ihn bitte ändern?“

Das ist Dein Problem

„Ich habe ein Problem mit der Codebasis – ich habe [hier ein schreckliches Geschäftsproblem einfügen] gefunden , das sich anscheinend größtenteils aus der Struktur ergibt, die beim Schreiben dieses Artikels verwendet wurde. Kann ich bitte Zeit haben, es zu ändern?“

Das ist dasselbe, aber es ist jetzt ein Problem für Ihren Chef, und daher ist es einfacher, Zeit für Sie einzuplanen, um daran zu arbeiten.

Code, der so schwer zu schreiben und zu warten ist, wie Sie es beschreiben, hat auch viel wahrscheinlicher solche entsetzlichen Probleme. Alles, was regelmäßig Ausnahmen fängt und frisst, wird dazu führen, dass alle Arten von Seltsamkeiten passieren können.