"Der beste Code ist gar kein Code"

Schreibt weniger Code!

Umer Mansoor

© Shutterstock / isak55

In diesem Artikel spricht Umer Mansoor, ein Software Entwickler aus San Fransisco, über die Wichtigkeit weniger Code zu schreiben und greift einige von Stack-Overflow-Mitgründer Jeff Atwoods wichtigsten Lektionen auf.

Vor nicht allzulanger Zeit setzte ich mich daran ein Projekt zu bereinigen, dass ich übernommen hatte. Die Zügel für das Refactoring wurden mir übergegeben, da das Projekt bereits während der Produktion etliche Bugs hatte. Ich steckte in einem Teufelskreis, in dem das Beheben alter Fehler neue einführte.

Ich tauchte also eines Wochenendes in den Quellcode ein und das Problem offenbarte sich schnell: Das Projekt war ein großes, haariges Chaos. Ich verwende das Wort groß, da es viel unnötigen, redundanten und eng gekoppelten Code gab. Mit haarigem Chaos meine ich nicht, dass der Code amateurhaft oder voller Shortcuts gewesen wäre. Tatsächlich war es genau anders herum. Es gab zuviel Magie und wohin ich auch schaute sah ich cleveres und grandioses Design. Das aber keine Beziehung zur eigentlichen Problemstellung hatte. Reflektionen, aspektorientierte Programmierung oder selbst erstellte Annotationen waren beispielsweise allesamt präsent. Das Projekt war ein übertechnisiertes Biest. Um es klarer Auszudrücken: Nach dem Refactoring war das Projekt auf weniger als die Hälfte der ursprünglichen Größe geschrumpft.

Ich bin mir sicher, dass die Entwickler des Projekts mit den besten Absichten geschrieben haben, doch ihre raffinierten Tricks haben sich gegen sie gewendet. Sie verbrachten viel Zeit mit regelmäßiger Wartung und Bugfixing. Die Kunden waren unzufrieden, dass die Software voller Fehler war. Die Entwickler fühlten sich scheiße, weil sich alle ständig über das Projekt beschwerten. Wer ist aber für ihr Elend verantwortlich zu machen? Für die langen Stunden, in denen sie nur Bugs fixen mussten und keinerlei Erfüllung in ihrer Arbeit fanden? Niemand als die Entwickler selbst sind dafür verantwortlich zu machen. Einer meiner Lieblings-Blogger, Jeff Atwood, schrieb, dass der beste Code gar kein Code sei.

Für die meisten Software-Entwickler ist es, weil sie ihren Code so sehr lieben, schmerzhaft zu erkennen: Aber der beste Code ist überhaupt kein Code. Jede neue, willentlich in die Welt gebrachte, Codezeile muss debugged werden, muss gelesen und verstanden werden, muss supported werden. Jedes Mal, wenn Sie neuen Code schreiben, sollte es widerwillig geschehen, unter Zwang, weil alle anderen Möglichkeiten bereits ausgeschöpft wurden. Code ist nur unser Feind, weil es so viele Programmierer gibt, die so verdammt viel davon schreiben. Wenn es gar nicht ohne Code geht, dann ist das nächst Beste sich kurz zu fassen.

Jeffs Standpunkt ist nicht zu leugnen. Als Entwickler juckt es uns in den Fingern clevere Lösungen zu entwickeln, von denen wir denken, sie würden uns professionell aussehen lassen oder uns helfen neue Tools oder Technologien zu erlernen. Wir konstruieren komplexe Schichten, um einfache Probleme zu lösen und rechtfertigen sie, indem wir sagen, sie wären „wirklich notwendig“. Allerdings müssen wir erkennen, dass je mehr Code wir schreiben, je mehr Magie wir anwenden, umso mehr Möglichkeiten und Türen bleiben auch für Bugs offen. Diese Bugs werden zurückkehren, um uns oder unsere Nachfolger heimzusuchen, in Form von Überstunden für das Fixen. Ich spreche natürlich nicht von aalglatten Tricks, um die Anzahl der Codezeilen zu reduzieren. Vielmehr sollten wir uns fragen, ob wir all diesen Code schreiben müssen, um das eigentliche Problem zu lösen. Ich habe etliche selbsterstellte ORMs und Thread-Pools während meiner Karriere gesehen, was mich zu einem anderen Punkt bringt:

Erfindet das Rad nicht neu. Bitte, bitte…

Aber belassen Sie es auf keinen Fall dabei. Denken Sie darüber nach, ob das fancy Framework überhaupt benötigt wird. Ein Projekt, an dem ich arbeitete, benutzte Hibernate zusammen mit den ergänzenden DAOs und DTOs, um eine einzelne einfache Query auszuführen. Ein anderes Projekt benutzte ein umfassendes Event-Handling System für einen Reflection API-basierenden Filter, um die Handler-Klasse abhängig vom Event-Typ zu finden und auszuführen. Es war eine geniale Lösung und es dauerte einige Zeit um herauszufinden, dass die von der IDE als „nicht verwendet“ markierten Methoden tatsächlich von der Reflection-API genutzt wurden. Das Sahnehäubchen: Das System behandelte nur eine Event-Art. Etwa fünf Klassen voller Code hätten in ein simples if-Statement zusammengefasst werden können.

if (event.type == THE_ONE_TYPE_THIS_SYSTEM_CAN_HANDLE) {
  process_the_event_and_return_result;
}

Der beste Code ist gar kein Code und der schnellste Code ist der, der niemals ausgeführt wird. Unser Ziel sollte es sein, unsere Lösungen so einfach wie möglich zu halten und von unserer natürlichen Tendenz zum Over Engineering, von cleveren Tricks und Design-Patterns fernzubleiben, bis nachgewiesen werden kann, dass sie absolut notwendig sind, um das Problem zu lösen. Komplexität ist unser schlimmster Feind. Ich beende diesen Beitrag mit einem ausgezeichneten Ratschlag von Jeff:

Wenn Sie das Schreiben von Code lieben – wirklich durch und durch lieben – dann lieben Sie es so sehr, dass Sie so wenig Code wie möglich schreiben.

Dieser Artikel wurde ursprünglich auf CodeAhoy veröffentlicht.

Aufmacherbild: Program code and computer keyboard von Shutterstock / Urheberrecht: isak55

Geschrieben von
Umer Mansoor
Umer Mansoor
Umer Mansoor ist ein Softwareentwickler aus San Fransisco. Zurzeit arbeitet er für Glu Mobile als Platform Manager und erstellt dort ein Cloud-Gaming-Backend. Davor arbeitete er als Head of Software bei Starscriber, wo er Hochleistungs-Telekommunikationssoftware entwickelte. Er blockt auf: CodeAhoy.com
Kommentare

Hinterlasse einen Kommentar

2 Kommentare auf "Schreibt weniger Code!"

avatar
400
  Subscribe  
Benachrichtige mich zu:
Alexander
Gast
Sehr interessante Ansicht! Man kann durchaus zustimmen. Auch schon als Anfänger (Student kurz vorm Bachelor) verspüre ich öfters den Drang „nach fancy“ Lösungen bzw. solche die in der Hauptapplikation wunderbar kurz bedient werden können, im Hintergrund aber mehrere Klassen benötigen. Andererseits widerspricht sich das Problem auch selbst. Öfters weiss man zu Anfang nicht exakt genug ob sich eine bestimmte Problemstellung im Projekt nun oft wiederholen wird oder nicht. Entsprechend weiss man dann auch nicht ob eine komplexe Abstrahierung/Pattern nicht doch sinnvoll wäre weil dies sonst am Ende erneut in viel Redundanz resultiert. Im Grunde schreibt man solche komplexen Dinge eben… Read more »
Harald Wellmann
Gast

Müssen Blogger sich jetzt schon selbst blocken?