In meinem Job als Entwickler setze ich mich tagtäglich mit sogenannten Code Smells, also Stellen im Code, die aufgrund schlechten Designs ein Refactoring nahelegen, auseinander. Einer dieser Code Smells, mit dem ich öfter vorliebnehmen muss, ist Dead Code (toter Code). Hier berichte ich kurz über meine Erfahrungen mit diesem Code Smell, und warum ich toten Code immer so früh wie möglich löschen würde.
Folgendes Szenario: Ein:e Entwickler:in findet eine Methode (oder gar ein ganzes Feature), die von der IDE zwar nicht als unbenutzt markiert wurde, sich nach kurzer Analyse aber dennoch als nicht genutzt herausstellt. Vielleicht wird der Code von einem undokumentierten oder nicht mehr benutzten API-Endpoint aufgerufen oder nur von anderem toten Code oder Unit-Tests. Der oder die Entwickler:in entscheidet sich, mit dem Team darüber zu reden.
„Das brauchen wir bestimmt nochmal. Lasst uns das lieber behalten.“ oder „Das Feature kommt im übernächsten Release wieder rein.“ könnte die Antwort der Kolleg:innen lauten.
Nach ein paar Monaten kommt ein:e andere:r Entwickler:in an dem Code vorbei. Diesmal lautet die Antwort des Teams „Ach ja, das Feature wollte der Kunde doch nicht mehr haben. Das kann wohl raus.“
Dann ist jetzt ja alles gut? Nein, denn in der Zwischenzeit musste dieser Code gegebenenfalls mit refactored oder beim Einbau neuer Features berücksichtigt werden, wurde von den Analysetools mit überprüft, von den Unit-Tests bei jedem Build getestet. Und generell hält das wiederholte darüber Stolpern („Huch, was macht dieser Code denn? Ach so, betrifft mich nicht.“) beim Entwickeln auf. Das Team hat in unserem Beispiel durch das Behalten des toten Codes nichts gewonnen, sondern nur Zeit und Aufwand vergeudet.
Deshalb lege ich allen Entwickler:innen nahe, toten Code frühzeitig zu löschen. Jedes Stück Code ist kontinuierlich teuer, denn es muss gewartet werden und beansprucht unser Arbeitsgedächtnis. Diesen Preis sollten wir nur für Code zahlen, den wir auch tatsächlich benötigen.
Und dabei sollte man keine Angst davor haben, zu viel zu löschen. Solange niemand gleich morgen diesen toten Code in „lebendigen“ Code umbauen will, wird es immer effizienter sein, diesen aus der Historie des Versionsverwaltungssystems zurückzuholen, sollte er in Zukunft wirklich noch einmal gebraucht werden.
Zusammenfassend gibt es für mich bezüglich toten Codes zwei wichtige Erkenntnisse:
- Nur weil die IDE nicht anzeigt, dass der Code ungenutzt ist, muss das nicht der Realität entsprechen, denn toter Code kann sich gegenseitig referenzieren oder durch andere Mechanismen zwar theoretisch, aber nie in der tatsächlichen Benutzung aufgerufen werden.
- Toter Code sollte frühzeitig gelöscht werden, statt ihn aufzuheben, um den durch ihn erzeugten Overhead zu vermeiden.
Martin Rybicki
Martin ist nach Abschluss seiner Promotion schon in diversen Projekten bei der PPI AG aktiv gewesen, unter anderem bei der Entwicklung von cysmo. Sein Fokus liegt auf besonders benutzerfreundlichen Cloud-Anwendungen und dem hochgradig automatisierten Entwicklungsprozess (#DevOps #Cloudnative) und ist als Mitglied der Zelle IT-Security auch an der Sicherheit der Anwendungen interessiert. Martin verantwortet als Director - Development die Entwicklungsprojekte bei crossnative.
