Clean Code: Gut rübergebracht!

Was für den eigenen Arbeitsplatz gilt, trifft auch beim Schreiben von Code zu: Ist er überschaubar und aufgeräumt, lässt sich besser damit arbeiten. Spätestens seit 2008, als das Buch «Clean Code» des amerikanischen Softwareentwicklers Robert C. Martin erschien, wissen Entwickler um die Bedeutung von sauberem Code. «Man geht davon aus, dass Entwickler rund 90 Prozent ihrer Zeit mit dem Lesen und nur 10 Prozent mit dem eigentlichen Schreiben von Code verbringen», erklärt Marko Marković, Senior Software Engineer bei bbv. «Damit Entwickler effizienter arbeiten können, muss Code einfacher lesbar sein. Das schafft man am besten über Clean Code.»

Sauber gehaltener Code, der sich auch ohne lange Schulung oder eine umfangreiche Dokumentation verstehen lässt, bringt Entwicklern entscheidende Vorteile: Sie erkennen viel schneller, wie Software aufgebaut ist, wie sie funktioniert – und wo man sie erweitern muss, damit sich Änderungen implementieren lassen. Schlechter, unübersichtlicher Code dagegen kann nur von einer bestimmten Anzahl Entwickler gewartet und weitergeführt werden – meistens sind das jene, die den Code von Anfang an und ohne Berücksichtigung von Clean Code geschrieben haben. Das erschwert sowohl die Fehlersuche als auch das Ändern oder Erweitern von Software. Auch verlängert sich dadurch die Einarbeitungszeit für neue Mitarbeiter. Dies lässt die Kosten für den Auftraggeber in die Höhe schnellen.

Zeitdruck erschwert sauberen Code

Doch was unter Clean Code genau verstanden wird, darüber scheiden sich die Geister: Mittlerweile finden sich im Internet unzählige Softwaredesign-Guidelines – mit teilweise unterschiedlichen Vorgaben, wie Code genau aufgebaut werden soll. Deshalb heisst Clean Code in der Praxis vor allem, sich festzulegen: «Im Prinzip kommt es bei Clean Code darauf an, sich auf gewisse Arbeitsweisen und Vorgaben zu einigen – vor allem dann, wenn man als Entwickler in einem Team arbeitet», erklärt Marković. Das kann etwa die einheitliche Benennung der technischen Module sein. Oder die Wahl der Strukturen sowie der Formatierung, mit der der Code gegliedert wird – und die dann überall konsequent eingehalten werden.

Damit die getroffenen Regeln und Vorgaben beim Schreiben von Code auch wirklich befolgt werden, müssen Entwickler Lernbereitschaft zeigen und gewillt sein, ihre bisherige Arbeitsweise zu ändern. Dazu ist auch Disziplin gefragt – was gerade unter Zeitdruck eine grosse Herausforderung ist: Den Code aufzuräumen und sauber zu halten, wird unter Stress von manchen schnell als Zeitverschwendung angesehen – schliesslich hat nicht Kosmetik, sondern das Fertigstellen von Software höchste Priorität. «Quellcode ist aber aufbauend», hält Marković fest. «Sobald ich beginne, im Code unsaubere Stellen zu hinterlassen und später auf diesem aufbaue, trage ich einen Klotz am Bein, der immer grösser und grösser wird und den man nicht mehr loswird.» Entwickler geraten so in einen Teufelskreis, der sehr viel Zeit kostet – und somit sehr teuer wird.

Kein Clean Code ohne offene Kommunikation

Entwickler müssen daher die Gelegenheit bekommen, sauberen Code zu schreiben. Das geschieht auf unterschiedlichen Ebenen: Werkzeuge wie Entwicklungs- und Testumgebungen oder Software-Lizenzen für gewisse Testsysteme müssen im Unternehmen bereitgestellt werden. Ebenso sollte allen Entwicklern die Vision des Software-Projekts klar sein: Sie wissen, wohin die Reise geht und kennen die Anforderungen, die an das Produkt gestellt werden, etwa hinsichtlich der Erweiterbarkeit und Wartbarkeit. Auch bestimmen Entwickler im Idealfall selbst, wie sie Software aufbauen und sich dabei organisieren möchten: Praktiken wie Pair Programming, Code Reviews, Coding Dojos und Test-Driven Development tragen bedeutend zu sauberen Code bei.

Um diese Bedingungen für Clean Code im Unternehmen zu schaffen, ist die offene Kommunikation mit dem Management unerlässlich. Wenn das Management weiss, weshalb Quellcode optimiert werden muss und warum Entwickler dafür auf gewisse Werkzeuge und Arbeitspraktiken angewiesen sind, stimmt es dem Aufräumen von Code eher zu, als wenn es im Ungewissen gelassen wird. Davon ist auch Marković überzeugt: «Wenn man dem Management die Risiken und Konsequenzen von schlechtem Code vermitteln kann, so dass es Verständnis für die Sicht der Entwickler zeigt und Code-Optimierungen zulässt, dann hat man eine wirklich tolle Zusammenarbeit erreicht.»