Der Herr nebenan ist gewissermaßen schon zu einem Symbol für diese kleine Reihe geworden, daher möchte ich ihn zunächst einmal vorstellen. Leider weiß ich seinen Namen nicht, und von seiner Adresse kenne ich nur die URL. Abgesehen davon könnte es sich ebenso gut um eine Dame handeln. Es ist ein Foto aus der Galerie Pixabay, es stammt von dem Autor Public Domain Pictures. Das besondere an dieser Galerie ist, dass die Bilder alle unter der “CC0″Lizenz stehen, das heißt, sie dürfen kostenlos und ohne Quellenangabe verwendet werden. Näheres dazu hier.
Nun aber zum eigentlichen Thema: Nummer 4 in der Reihe der “Sieben Dinge, die dein Chef nicht über Softwareentwicklung weiß” ist laut dem Autor: “Einige Entwickler können tatsächlich weniger als 0 Zeilen Code schreiben”. Das klingt zunächst verwirrend, ist aber tatsächlich auch real. Denn was ist das Gegenteil von “Schreiben”? Na gut, “Lesen” könnte man sagen, aber im aktuellen Kontext ist das wohl eher “Löschen”. Warum ist das gut?
Nun, an dieser Stelle weiche ich etwas ab von John Sonmez, denn was er eigentlich meinte, sind Programmierkollegen, die so schlecht sind, dass sie der Abteilung eher Geld zahlen müssten, anstatt etwas zu verdienen. Doch diese Situation hatte ich gar nicht im Sinn, als ich die Überschrift las. Mein Gedanke ist eher das Thema “Refactoring”. Dabei kann es nämlich durchaus passieren, dass am Ende weniger Codezeilen im Projekt sind als zu Beginn.
Dead Code
Das hat zum Teil etwas mit dem Löschen von “Dead Code” zu tun, also von Code, der gar nicht mehr angesprungen wird. Sowas kann passieren, und da sollte man ab und zu mal ein entsprechendes Tool drüberlaufen lassen. Die MZ-Tools für VB und VBA haben eine nützliche Funktion dafür integriert.
Im Zuge dieser Aktionen fallen vielleicht weitere Funktionen auf, die nicht mehr benötigt werden, weil sie ursprünglich nur von dieser einen Funktion aufgerufen wurden, die nun eliminiert wurde. Das kann sich quer durch den Code ziehen und am Ende auch einige Unit-Tests betreffen. Was übrig bleibt, ist hoffentlich immer noch lauf- und funktionsfähig. Ersteres checkt der Compiler, letzteres die verbleibenden Unit-Tests.
Das Ergebnis ist weniger Code, der schneller übersetzt und getestet wird. Und wenn ein User fragt, warum das Setup plötzlich deutlich kleiner ist, erkläre es ihm einfach. User, denen dies auffällt, sind vielleicht sehr gut als Testpersonen für die nächste Beta geeignet, denn sie achten auf Dinge, die vielen anderen entgehen.
Weniger ist mehr
Auch ein anderes Vorgehen beim Refactoring produziert negative Codezeilen. Oft schreibe ich eine Funktion um, die mir im ersten Lauf viel zu kompliziert geraten ist. Da ich nach dem Programmieren oft viel besser weiß, was ich eigentlich tun will, was funktioniert und was nicht, wird die Funktion/Methode/Klasse beim zweiten mal vielleicht besseren Code haben, gepackter und übersichtlicher.
So entsteht durch Reduktion Mehrwert. Negative Codezeilen. Weniger ist mehr.
Neueste Kommentare