Dreckiger Code kostet mehr als nur Zeit

Es wirkt immer so einfach, sauberen Code zu schreiben. Am Anfang steht die Motivation und jeder scheint genau zu wissen, was er zu coden hat. Dabei bleibt der Code übersichtlich und erfüllt seine Funktion.

Doch bei Code ist es so eine Sache: Code ist niemals fertig. Code wächst wie ein Geschwür und macht irgendwann viel, viel mehr als ursprünglich beabsichtigt war. Neue Leute schauen sich den Code an und verbessern Funktionen, produzieren an anderer Stelle durch diese Verbesserungen allerdings Bugs und schon beginnt die Spirale sich zu drehen: Man verbringt viel mehr Zeit mit der Bugsuche, als mit dem Schreiben von neuem Code.

Ich würde niemals so coden!

„Meine Codes waren übersichtlich, was ist das für eine unfassbare Scheisse?!“ schreit so ziemlich jeder Entwickler mindestens einmal in seinem Leben. Und ja, tatsächlich ist der Code unfassbare Scheisse, aber jeder andere Entwickler würde das über den Code eines anderen Entwicklers sagen. Das liegt nicht daran, dass die Leute absichtlich so einen Mist programmieren. Es liegt an Deadlines, Hotfixes und nicht zuletzt auch an den Einflüssen von außen. Projektleiter sind keine Coder und geben nach besten Wissen und Gewissen Deadlines zum Kunden oder zur Geschäftsleitung vor. Dabei haben diese Menschen Erfahrungswerte und schätzen ein, wie lange ein Code offenbar benötigen könnte.

Coder haben einen Ehrencodex und wollen schwierige Dinge natürlich möglichst schnell coden. Daher geben diese Menschen auch schon sehr positive Einschätzungen ab.

Wahrheiten sind so wichtig

Coder müssen realistischer agieren. Mir persönlich fällt das auch unglaublich schwer. Tatsächlich habe ich festgestellt, dass meine eigenen Einschätzungen um den Faktor 4 langsamer sind, als ich dachte. Mir ist das noch immer peinlich, es zuzugeben, dass ich für eine Lösung viel länger brauche. Aber ich bin der Coder. Es ist mein Job, möglichst geilen Code abzuliefern. Wenn ich Dachdecker wäre, müsste ich die Statik auch einhalten und solch ein Prozess dauert hat.

Auch wenn es meinem Teamleiter nicht gefällt, muss ich als Coder dazu stehen und meine Einschätzung anders machen:

  • Großzügiger
  • Realistischer
  • Genauer

nennen und es ist meine Pflicht, dem Teamleiter Verzögerungen mitzuteilen. Es ist meine Pflicht, die Qualität meiner Arbeit zu verteidigen und mein Job ist möglichst sauberer Code, der die gestellte Aufgabe erfüllt. Dreckiger Code erfüllt die Aufgabe auch, bis zu dem Punkt, an dem ich was an dem Code verändern muss.

Wenn die Deadline kommt

Die Deadline kommt, sie ist das Damoklesschwert und sie ist der bösartige Cousin, der einem früher immer den Lolli geklaut hat. Selbst wenn die Deadline nur noch Stunden entfernt ist, solltest Du als Coder die Qualität deines Programmes um jeden Preis beibehalten. Du wirst das Ding eh nicht ohne Bugs und/oder weitere Kundenwünsche abliefern können, also solltest du zukunftsorientiert arbeiten, damit du die Bugs wirklich einfach fixen kannst und die Kundenwünsche einfach nachziehen kannst. Da sparst du Zeit.

Code fixen? Wie denn?!

Guter Code ist wie ein guter Song: Du erkennst ihn, wenn du ihn siehst. Du musst kein Beethoven sein, um schlechte Codes zu erkennen. Wenn du in Teilprogrammierungen reingehst und schon siehst, dass der Code ziemlich gruselig aussieht, kannst du ihn jederzeit verbessern.

Code ist wie ein Zimmer: Du betrittst den Raum und räumst erstmal ein wenig auf. Dabei bist du vorsichtig, denn das ist noch immer nicht dein Zimmer. Wenn ein Kissen auf dem Boden liegt, hebe es auf. Wenn eine Variable $a heißt, gucke nach, was die Variable macht und benenne sie entsprechend um.

Das sind nur Kleinigkeiten, aber du schaust die jeden Tag irgendwelche Codes an. Und wenn du jedesmal nur ein kleines bisschen aufräumst, verbesserst du im gesamten Projekt den Code, ganz nebenbei.

Frei nach: https://bennettgarner.medium.com/what-your-messy-code-is-costing-you-3317e419df3a

Photo by Robert Bye on Unsplash


Kommentare aufgrund von Fehlern kurz mal deaktiviert.