Wer hat das geschrieben? / Sudo Null IT-Nachrichten

Der CTO und der Entwickler untersuchen gemeinsam den Legacy-Code, um den Fehler zu beheben. Die Qual nimmt kein Ende und sie sind bereits bereit aufzugeben. „Wer hat diesen Mist überhaupt geschrieben?“ fragt der technische Leiter. Entmutigt blickt er auf die Schuld des Idioten. Es stellt sich heraus, dass er es geschrieben hat.

Treffen Sie unsere Hauptfigur – Jake. Er ist ein Entwickler, der kürzlich vom Unternehmen für ein Projekt eingestellt wurde, das sich im siebten Jahr befindet. Während des Onboarding-Prozesses wurde Jake damit beauftragt, einen Fehler zu beheben, und dazu musste er in die Tiefen des Legacy-Codes graben. Bewaffnet mit all seinem Wissen und Verständnis der Zusammenhänge, trat er in den Abgrund. Alles hätte einfach sein sollen. Schließlich ist dies eine Aufgabe für einen Anfänger. Was könnte passieren? (Irgendwo ertönte ein zynisches Lachen)


Nach den ersten zwei Stunden verlor Jake jeglichen Enthusiasmus, mit dem er sich an sein Geschäft machte. Er verzettelte sich vor Ärger und versuchte, all die durcheinandergebrachten Hierarchien zu entschlüsseln, die sich als rätselhafter herausstellten als der Stammbaum der königlichen Familie. Lange Methoden, die von allem ein bisschen können. Heimtückische implizite Parameter, die in dunklen Ecken lauern. Er kämpfte wütend mit den Gedanken eines unbekannten Genies, aber alles umsonst. Zweifel und Ängste benetzten ihn wie Tau (oder brachte ihn das nur zum Schwitzen?). Ist die Person, die dies geschrieben hat, ein außergewöhnlicher Verstand oder nur eine Art Bastard? Jake mochte den Legacy-Code überhaupt nicht. Sein Programmierstil passte nicht in die Codebasis. Während er versuchte herauszufinden, was darin vor sich ging, läuteten alle bekannten Glocken. Nur eine Art Horror. Alles muss sofort neu geschrieben werden.

Die meisten von uns waren in Jakes Schuhen und verspürten den unwiderstehlichen Drang, etwas neu zu schreiben, das nicht in unsere persönliche Entwicklercharta passte. Sie schauen und sehen einige kontinuierliche Verbrechen gegen die Sauberkeit des Codes. Das verleitet dazu, aus Trotz einen weiteren Stein auf die zerbrochene Scheibe zu werfen. Was kann in diesem schrecklichen Programmierstil behoben werden?

Nun, diese Gefühle sind normal. Und doch kennen Sie sicherlich nicht den Kontext, in dem die Person diese Entscheidungen getroffen hat. Versuchen Sie, seine Motive zu verstehen, bevor Sie urteilen und auf Stolz stoßen. Vielleicht mussten aufgrund der knappen Fristen Abstriche gemacht werden. Wenn wir über ein Startup sprechen, wird sich das Team mit technischen Schulden befassen, wenn die geschäftigste Zeit vorüber ist. Es ist möglich, dass Investitionen erforderlich sind, um das Projekt fortzusetzen, was häufig vorkommt. Es gibt noch einen weiteren Grund: Angefangen hat alles einfach, aber aufgrund der Anforderungen musste ich den Kurs in Richtung größerer Komplexität ändern – alle anderen Optionen waren damals noch schlechter, und diese hier schien in Bezug auf Geschwindigkeit und Kosten optimal zu sein. Vielleicht wurden neumodische Technologien nicht verwendet, weil sie dann noch instabil waren und es keine Alternativen gab. Welche anderen Erklärungen könnte es geben? Jemandes Ego? Leider ist dies ein häufiger Grund. Oder vielleicht wusste die Person einfach nicht, wie sie es besser machen sollte. Es ist auch kein Verbrechen. Wie mein Kollege sagte:

„Wir alle schreiben Code auf die bestmögliche Weise im aktuellen Moment unter den aktuellen Umständen.“

Sie können sich so sehr empören, wie Sie möchten, aber alles von Grund auf neu zu schreiben, ist zu kostspielig und riskant. Bei einem der Projekte, an denen ich beteiligt war, entschieden die Entwickler, dass die Codebasis ein Dump war, der nicht hingenommen werden konnte. Wir waren laut und wütend und weigerten uns, die Verantwortung zu übernehmen, bis wir eine vollständige Neufassung erhielten. Jeder Fehler wurde der Codebasis und engen Fristen zugeschrieben, aber nicht uns. Wir haben genug Lärm gemacht und die Erlaubnis bekommen, alles umzuschreiben. Ja, ich scheine vergessen zu erwähnen, dass dies ein Start-up war, das dringend Investitionen benötigte. Natürlich versiegte der Cashflow auf halbem Weg, und uns gingen die Mittel aus. Aber jetzt haben wir alles nach Vorschrift gemacht und sind auch nach Vorschrift auf den Grund gegangen.

Natürlich ist die Arbeit mit einer schlechten Codebasis mühsam und schwierig. Junge Entwickler haben selten die Fähigkeit, der Versuchung zu widerstehen, alles neu zu schreiben, was ihnen nicht gehört. Anstatt das Problem und den Kunden zu verstehen, wollen sie zeigen, wozu sie in der Lage sind, und den Zweck des Projekts vergessen.

Egal was wir tun, es wird immer eine Art Bodensatz in der Codebasis geben. Was kann getan werden, um dies zu beheben? Für den Anfang beschweren Sie sich nicht. Klagen hört sich niemand gerne an, noch mehr Vorwürfe, dort etwas falsch gemacht zu haben. Das würde dir auch nicht gefallen. Versuchen Sie für den Anfang, sich an die Regeln der Pfadfinder zu halten und Ihre Baustelle jedes Mal etwas sauberer zu hinterlassen, als sie am Anfang war. Bauen Sie zerbrochene Fenster ein, wenn Sie eine freie Minute haben, und bringen Sie anderen bei, dasselbe zu tun. Fügen Sie Tests hinzu, bevor Sie Fehler beheben, und nach einer Weile werden Sie sich sicherer fühlen, wenn Sie Änderungen vornehmen oder umgestalten. Zeigen Sie anderen durch Ihr Beispiel, dass Sie nach und nach gemeinsam eine bessere Codebasis erstellen können. Sie werden es nicht an einem Tag bekommen, aber nach einer Weile werden Sie es nicht wiedererkennen.

Wenn es wirklich sehr schlecht ist, weisen Sie auf bestimmte Fehler hin und erklären Sie, warum Sie denken, dass es Fehler sind. Wie wirkt sich ihre Behebung auf das Geschäft aus? Machen Sie kurz- und langfristige Verbesserungspläne, die einen gewissen Wert bringen. Und vergessen Sie nicht: Das nächste Mal, wenn Sie Feuer löschen müssen, kann jeden Moment kommen. Scheuen Sie sich nicht, Abstriche zu machen, die Hauptsache hier ist, klarzustellen, dass Sie zu diesem Fragment zurückkehren und Änderungen vornehmen müssen. Schließlich wird man nicht dick, wenn man an Feiertagen viel Kuchen isst, sondern wenn man jeden Tag ein bisschen zu viel isst.

Similar Posts

Leave a Reply

Your email address will not be published.