Coder sind Messis. Ich habe bisher kaum ein größeres Projekt in den Fingern gehabt das keine Leichen im Keller hatte.
Das gängige Problem ist natürlich der “gewachsene” Code. Ein Projekt wird den Wasserfall runter entwickelt, geht live, geht in die Wartung. Dann kommt ein Feature dazu, ein anderes wird abgeschaltet. Am besten gibt es noch zig Schalter und Properties mit denen Teile des Quellcodes aktiviert oder deaktiviert werden könnten. Theoretisch.
Böse wird es dann wenn man auf Basis eines alten Projektes ein neues aufsetzen muss. Dann hat man diese bestehende Code Basis. So richtig weiß man nicht was da so alles passiert und dann kommt der Onkel aus der Projektleitung uns meint das man dieses und jenes Feature ja dann in Phase 3 oder 4 vielleicht brauchen wird, daher soll man es doch bitte im Code lassen.
Bullshit. Ehrlich das ist Bullshit. Vor 50 Jahren vielleicht als Quellcode noch auf Lochkarten gepresst wurde, da hat es Sinn ergeben alten Code aufzubewahren. Heute sollte es Teil eines jeden halbwegs soliden Refactorings sein das man unbenutzen Code rausschmeißt.
Warum?
- Toter Code gerät in Vergessenheit. Was man nicht wartet wird vergessen. Irgendwann ist der Schöpfer des lähmenden Brockens nicht mehr im Team, gar nicht mehr im Unternehmen und dann findet sich der neue Entwickler im Tal der WTF’s wieder.
- Ungenutzer Code wird allgemein schlechter getestet. Klar gibt Unit- und Integrationstests, aber wenn die Funktion nicht mehr im Testplan ist steigt die Wahrscheinlichkeit von Fehlern kontinuierlich an. Und spätestens wenn man ihn dann wieder einbinden will fängt man an im Nebel zu stochern weil irgend was nicht funktioniert.
- Ungenutzer Code liegt bei Refactorings im Weg. Wir eine Bibliothek angepasst oder etwas an der Codebasis verändert von welcher der tote Code abhängt entstehen unnötige Aufwände. Im schlimmsten Fall wird ein Refactoring gar als unmöglich eingestuft nur weil da ja noch eine Klasse von abhängt oder mit refactored werden müsste.
- Ungenutzer Code macht ein Projekt unübersichtlich und komplex. Dadurch wird es schwerer neue Funktionen zu integrieren, die Bibliothek an anderer Stelle zu verwenden und neue Entwickler in ein Projekt zu integrieren.
Alles in allem wiegen diese Probleme um so schwerer, je monolitischer und größer ein Projekt allgemein ist. Eine feine kleine Bibliothek wird von Natur aus dazu neigen weniger Leichen zu beinhalten als ein riesen eCommerce Framework. Nichtsdestotrotz möge ein jeder Entwickler und Projektleiter mal in sich gehen wenn er das nächste Mal ein Feature abschaltet ob der Code wirklich noch gebraucht wird.
Und ganz ehrlich, es tut niemandem weh einen Tag im Git zu machen und den Code rauszuwerfen. Denn wenn man wirklich in nem Jahr eine Funktion wieder braucht, dann schaut man nach was man da rausgeworfen hat und refaktoriert eben genau dann und spart der Weile eine Menge Arbeit und WTFs. Ob man dabei dann auf Basis des gelöschten neu implementiert oder direkt wieder verwendet ist dann auch egal.