Ein wichtiges Element beim programmieren ist Refactoring. Wer das nicht macht ist doof

Bei langlebigen Projekten wie snippr, werden sehr oft neue Features eingebaut und wenn man viele neue Sache einbaut entsteht schnell Chaos.

Neue Funktionen, über die man sich vorher nie Gedanken gemacht hat, passen nun einmal nicht immer 100%ig in den vorhandenen Code. Das liegt einfach daran dass man zwar defensiv programmieren kann, aber eine Glaskugel die alle möglichen Einsatzmöglichkeiten anzeigt habe ich leider nicht. So muss man, weil ja alles gestern fertig sein soll, die neue Funktionalität erstmal irgendwie rein zaubern. Das führt dann auf Dauer zu immer unübersichtlicheren Spaghetti Code.

So ist es eine logische Schlussfolgerng dass bestehender Code angepasst werden muss. Viele Leute haben jedoch Angst alten Quellcode anzupassen - und mit alt ist jetzt nicht unbedingt 2 Jahre gemeint sondern manchmal auch nur drei Wochen.
Fire and Forget a.k.a. Quick and Dirty rächt sich bei langfristig angelegten Projekten sehr schnell. Was man heute hinschludert versteht man eine Woche später schon nicht mehr. Und wenn es etwas gibt was wichtig ist, so ist es die Verständnis des (eigenen) Codes mit dem man tagtäglich arbeitet!

Wer Angst vor seinem eigenen Quellcode hat macht etwas verkehrt wenn er ihn nicht neu schreibt! “
“Läuft, bloss nicht anfassen den Scheiß! Im Moment funktioniert es, hoffen wir dass es so bleibt!”- diese Einstellung hört man oft, ist aber die Wurzel allen Übels für schlechten Code. Schlechter Code an der einen Stelle zieht mehr schlechten Code dort und auch an anderen Stellen nach sich. “Da haben wir das auch so gemacht und das läuft ja auch irgendwie…” - solche Sätze hört oder sagt man dann - fatal! Wenn sich das Gefühl “Das ist eh alles schrott, dann muss ich mir hier auch keine Mühe mehr geben” breit macht, wird das Projekt zumindest auf technischer Seite scheitern.

Die Gesetze der Physik gelten für die Softwareentwicklung nicht, bis auf eins - die Entropie. Die Entropie beschreibt das Maß der Unordnung in einem System. Dummerweise besagen die Gesetze der Thermodynamik dass die Entropie im Universum ein Maximum an. Genauso geht es mit der Software weiter, wenn man den Code vergammeln lässt.

Ich investiere jeden Tag durchschnittlich eine Stunde zum refaktorisieren von bestehenden Code. Mal mehr mal weniger, aber ich mache regelmässig Dateien auf und passe Klassen/Methoden den neuen Umständen an.
Das muss nicht nur aufgrund von neue Features sein - ich bin zwar schon 30, lerne jedoch trotzdem noch fast jeden Tag neue Möglichkeiten wie ich Sachen umsetzen kann.
So kommt es häufig vor, dass die hochmoderne Jetzt-aber-hallo-und-hier-reitet-die-Speerspitze-des-Machbaren-auf-glühenden-Hufen-vorbei-Technik die ich gestern noch eingesetzt habe eine Woche später schon wieder durch etwas noch bessseres übertrumpft wird. Also heißt es alten Code aufreissen und durch neue tollere Sachen ersetzen. Nichts ist schlimmer als wenn man dem Quellcode ansieht dass er über einen längeren Zeitraum entstanden ist und man 10 verschiedene Möglichkeiten nutzt ein Ziel zu erreichen.

Ein weiterer Vorteil ist dass man so auch den Quellcode von Kollegen kennenlernt und weiß woher der Hase läuft. Wenn der Kunde anruft und es tritt ein Fehler auf und man sieht dann das erste Mal den Code dauert es halt sonst länger, weil man sich erst reinfuchsen muss. So hat jeder der Projektbeteiligten schonmal (fast) alles gesehen und kann problemlos für den anderen einspringen. Auch passt sich der Quellcode der Beteiligten an und man erkennt nicht sofort wer was geschrieben hat- der Code wird um einiges einheitlicher.

Das natürlich beim umstellen Fehler passieren können und Sachen nicht mehr funktionieren gehört leider dazu. Da kommen wir dann zum Thema Unit-Testing…aber nciht mehr heute…