Programmieren macht Spaß. Doch was, wenn man den Spaß mit anderen Teilen will? Und wie sorgt man dafür, dass der Spaß auch dann anhält, wenn man länger an einem Projekt arbeitet? Ein paar Grundlagen und eine gemeinsame Sprache helfen dabei. Hier möchte ich ein paar Bücher vorstellen, die dies zu ihrem Thema machen.
Mein erster Tipp: Design Patterns. Design Patterns (zu deutsch: Entwurfsmuster) sind abstrakte Problemlösungen für wiederkehrende Probleme. Die bekannteste Liste von Patterns wurde 1995 von der "Gang of Four" (kurz: GoF; Erich Gamma, Richard Helm, Ralph Johnson und John Vlissides) veröffentlicht: Design Patterns: Elements of Reusable Object-Oriented Software. Die GoF-Patterns sind dabei wiederkehrende Elemente aus der Objektorientierung. Bekannte Muster sind beispielsweise die Factory oder der Observer. Es gibt aber eine ganze Reihe mehr von ihnen zu entdecken! Muster werden dabei stets auf die Problemdomäne angepasst - sie sind also keine feststehende Code-Bibliothek. Das GoF-Buch wurde 1994 veröffentlicht und orientiert sich an C++ und Smalltalk. Doch keine Angst: die Beispiele sind auch ohne Kenntnisse der Sprachen gut zu verstehen. Insbesondere eignet sich das Buch wunderbar als Nachschlagewerk. Aus der Head-First-Reihe von O'Reilly erschien ein auf Java kokussiertes Buch über Design Patterns: Head First: Design Patterns. Es soll inhaltlich gut sein (ich kann mich hier nur auf Empfehlungen anderer verlassen), allerdings eignet es sich weniger gut als Nachschlagewerk. Meiner Meinung ein absolutes Muss: Zum einen helfen die Ansätze dabei, häufige Probleme elegant auf einer sehr abstrakten Ebene zu lösen. Zum anderen schaffen sie eine gemeinsame Sprache: es ist schön, wenn alle Beteiligten unter "factory method" das gleiche verstehen 
.
Nachdem nun Code entstanden ist, stellt man meist fest, dass er nicht ganz die erhoffte Qualität hat. Es werden Patterns eingeführt, Code wird umgezogen, Methoden werden geteilt, usw. Diese internen Umstrukturierungen, die die eigentliche Arbeitsweise nach Außen hin nicht verändern, nennen sich Refactorings. Martin Fowler widmete diesem Thema ein gleichnamiges Buch. Es stellt gängige Probleme vor, und erklärt, wie diese sich lösen lassen. Dieses Wissen sollte in jeden Werkzeugkasten eines Programmierers gehören! Die Art, wie das Buch geschrieben ist, führte zu Kritik. Ich möchte daher auf einen guten Artikel von Jedd Adwood verweisen. Er stellt den Begiff "Code Smell", also "übel riechenden Code", in den Mittelpunkt und beschreibt, auf welche typischen Muster man achten sollte, um Code verständlich und wartbar zu halten. Meine Empfehlung: beides kritisch lesen und selbst ein Bild machen.
Der Einsatz von Design-Patterns und Refactorings hilft sehr dabei, "sauberen" Code zu schreiben. Doch was heißt das eigentlich - "sauber"?
Robert C. Martin befasst sich in seinem Werk "Clean Code: A Handbook of Agile Software Craftsmanship" mit dieser Frage. Er spricht dabei eine ganze Reihe Empfehlungen aus: wie soll Code Commentiert werden, welche Länge soll eine Methode haben, und wie sollen sie überhaupt heißen? Die Beispiele sind in Java geschrieben, aber grundsätzlich für alle Programmiersprachen gültig. Das Buch relativiert dabei viele Aussagen: an manchen Stellen schreibt Oncle Bob, das Ausnahmen nicht immer vermieden werden können. Dennoch regt es zumindest in meinem Umfeld immer wieder Diskussionen an - zurecht, wie ich finde. Denn gerade durch Hinterfragen und Diskussionen lernen die Beteiligten oft mehr, als durch pures Lesen. Das Buch sollte jeder Entwickler einmal gelesen haben - eigene Meinungen sind meines Erachtens aber dennoch erlaubt. Eine deutsche Community zu Themen des Buches gibt es unter dem Namen "Clean Code Developer". Die Webseite ist einen Besuch wert und baut auf den Werten des Buches auf, meiner Meinung nach ist ist die Webseite aber kein Ersatz für das Buch. In diesem Sinne: Viel Spaß beim Lesen!