build broken

Seit dem ich Code schreibe, steht für mich ein klarer und verständlicher Code an oberster Stelle. Ich hatte dann vor ca. eineinhalb Jahren Code Complete und The Pragmatic Programmer gelesen und dadurch die ersten Antworten bekommen, WIE man den Code unter Kontrolle hält. Anfang 2009 sind wir – ich und Stefan – durch den Podcast von Hanselman und Uncle Bob auf das Thema SOLID gestoßen – und darüber auch eine ausgiebige Diskussion geführt. Eins war uns klar: die Ideen, die dahinter stecken, könnten die Antwort auf unsere Suche sein.

Deshalb hat mich sehr gefreut, als ich von der Seite Clean Code Developer erfahren habe. Ihr Inhalt hat mich sofort begeistert. Sie beschreibt einen – wahrscheinlich DEN – möglichen Weg um ein professioneller Softwareentwickler zu werden.

Am letzten Wochenende auf dem .NET Open-Space-Süd habe ich das große Vergnügen gehabt, Stefan Lieser, einen der Gründer von Clean Code Developer-Seite kennen zu lernen und so konnte ich in den 2 Tagen viel über den Weg von einem Creepy-Code-Programmer zu einem Clean-Code-Programmer erfahren.

Die Grundidee ist ganz einfach: genauso wie ein Arzt oder ein Architekt, muss auch ein professioneller Softwareentwickler Verantwortung für seine Arbeit und für die Ergebnisse dieser Arbeit übernehmen. Er/sie muss sicherstellen, dass der Code korrekt, evolvierbar und effizient ist und dass er selbst immer sein Bestes gibt. Damit ist nicht gemeint, dass jeder ein Guru sein muss. Nein, professioneller Softwareentwickler ist derjenige, der an einem Wertesystem festhält und immer die Qualität des Codes vor den Augen hat.

Viele werden sagen “Wozu die Mühe, es funktioniert auch so!”. Klar, wenn man nur für den Jetzt programmiert. Dann, nach kurzer Zeit passiert das unvermeidliche: jemand – oder der Entwickler selbst – muss den furchterregend schlechten Code bugfixen/verändern. All diese Entwickler, die solche Aufgaben hatten, werden Tests zu schätzen wissen. Diese Tests kosten zwar etwas Mühe aber bescheren einem einen ruhigen Schlaf.

Zu einem genauso großen Problem führt, wenn man das elementarste aller Prinzipien nicht respektiert: Don’t-Repeat-Yourself (DRY). Wie oft passiert, dass man eine Methode, ein Verhalten anpassen muss und überall nach verstreuten Kopien vom Code suchen muss? Könnt ihr jedes Mal garantieren, dass ihr alle erwischt habt? Das wäre keine Frage, wenn der Entwickler des Codes das DRY-Prinzip respektiert.

Der Code, den ein Entwickler schreibt, gehört meistens nicht ihm. Ich bin sicher, keiner von uns möchte als “Creepy-Coder” beschimpft werden, wenn jemand anderer unserer Code verstehen oder weiterentwickeln muss.

Nimmt eure Arbeit ernst und werdet ein professioneller Entwickler. Ihr werdet nach kürzester Zeit die Freude an einem korrekten und qualitativen Code entdecken und auch eure Teamkollegen und Chefs werden dafür dankbar sein.

Geschrieben am Dienstag, 14. Juli 2009 um 3:14 pm und ist zu finden in Clean Code Developing. Du kannst die Antworten zu diesem Thema verfolgen unter RSS 2.0 feed. Du kannst Antwort, oder trackback von deiner Seite.