Boehrsi.de - Blog

Ich hatte schon häufiger das Thema der Codequalität hier im Blog und habe dafür geworben selbige hochzuhalten. Soll heißen bestehenden Code auch mal zu modernisieren, während der Entwicklung Dinge zu optimieren, statt zu duplizieren und Fehler die man zwischendurch entdeckt direkt zu beheben. Es gibt noch viele, viele weitere Möglichkeiten die Codequalität zu steigern, doch darum soll es heute gar nicht gehen.
Ich wollte mal konkret mitteilen warum ich es für wichtig halte nicht nur links und rechts Dinge anzubauen, sondern eben auch das große Ganze im Blick zu behalten. Ich habe vor kurzem die Ehre gehabt in ein halbwegs umfangreiches Projekt eine neue Funktion einzubauen, welche auf bestehender Logik aufsetzt und diese erweitert. An sich war der Ansatz recht simple, denn es sollte einfach ein bestehender Flow erweitert und mit verschiedenen Kontexten erneut ausgeführt werden. Alle anderen Abläufe, die auf diesem bestehenden Flow aufsetzen, mussten entsprechend angepasst werden, sodass sie den neuen Kontextbezug auch erfassen. Generell wäre das ein Aufgabe für einige Tage gewesen, allerdings wurde alles wesentlich umfangreicher.

Grund dafür war nicht ein unbekanntes Level an Komplexität, sondern die Verteilung von Logik, die mit dem bestehenden Flow arbeitet, auf unzählige Klassen, gerne auch im Bereich der UI. Zusätzlich wurde von allen Seiten wild in die Datenbank geschrieben, ohne eine ordentliche Abstraktion und mit unseren lieben Freunden, den Magic-Strings. Entsprechend investierte ich einige Tage für das eigentliche Feature und mehr als eine Wochen, um die diversen Stellen zu identifizieren, welche um drei Ecken auf Dinge zugriffen die mich tangierten und vor allem um quasi den gesamten Datenbank-Layer an einem Ort zu bündeln und sicherer zu machen. Denn was kann man sich besseres vorstellen, als eine bunte Auswahl von SQLite Queries, immer wieder als reinen String geschrieben, ohne Konstanten und entsprechend auch mit Tippfehlern hier und da.
Abseits vom exorbitant hohen Aufwand die Basis für das eigentliche Feature zu bauen, ist vermutlich auch naheliegend das trotz selbigem irgendwo bestimmt noch ein gut versteckter Ort zu finden ist, wo die Logik vielleicht nicht optimal an die neuen Gegebenheiten angepasst wurde. Denn neben Mehraufwand ist schlechter Code eben auch ein Garant für Fehler. Wer ihn schreibt versteht ihn vielleicht noch, wenn er zwei Tage später drauf schaut, aber spätestens der nächste Entwickler weiß nichts damit anzufangen und baut im schlimmsten Fall eine ähnlich unverständliche Struktur direkt daneben. Setzt man dieser Spirale nicht früher oder später ein Ende, sind teils extreme Refactorings nötig, um mitunter triviale Funktionen zu ergänzen oder schlicht um vorhandene Fehler zu beheben.
Insofern kann ich nur sagen, behandelt euren Code gut oder wundert euch nicht wenn selbiger euch später in den Allerwertesten beißt.