Code Simplicity – The Science of Software Development
Muss ein Buch dick sein, damit es in eine höhere Preiskategorie steigt? Oder darf ein Buch dünn daherkommen und seinen Preis durch den Inhalt definieren? Wer eine kompakte Darstellung liebt, erhält von diesem Buch wertvolle Tipps – vorausgesetzt, Werke wie "Clean Code" oder "The Art of Readable Code" sind unbekannt.
- Michael Müller
Max Kanat-Alexander
Code Simplicity – The Science of Software Development
Sebastopol, CA 2012
O’Reilly Media
viii + 78 Seiten
€ 20,–
ISBN 978-1-449-31389-0
Muss ein Buch dick sein, damit es in eine höhere Preiskategorie steigt? Oder darf ein Buch dünn daherkommen und seinen Preis durch den Inhalt definieren? O'Reilly hat ein paar dünne Bücher in einer Preiskategorie herausgebracht, in der sich sonst dickere Werke tummeln. Lieber 100 Seiten Kompaktes als 500 weitschweifige. Vor diesem Hintergrund ist das vorliegende Buch zu betrachten, das mit deutlich weniger als 100 Seiten recht dünn ausfällt.
Gleich zu Beginn trägt der Autor dick auf, behauptet, es gebe bisher keine wissenschaftlichen Regeln zum Softwaredesign und liefert deshalb seinerseits "die" Formel des Softwaredesigns. Irgendwie kommt die einem bekannt vor; drückt sie doch aus, was in Büchern zu IT-Projektmanagement nachzulesen ist.
Ebenfalls nicht neu ist der Vergleich mit dem Bauwesen, mit der besonderen Bedeutung des Architekten, guter Planung und der Ausführung der Gewerke durch Spezialisten. Auf der anderen Seite der Softwareentwickler. Nichts stehe zwischen ihm und dem Sourcecode. Nur der Entwickler sei verantwortlich für das Design. Und dafür brauche es die Wissenschaft und Formel dieses Buchs. Da blendet der Autor die unterschiedlichen Rollen von Softwarearchitekt, Programmierer, Tester et cetera aus. Tatsächlich gibt es agile Strömungen, die die Rolle des Softwarearchitekten als überholt ansehen. Andere halten diesen (ab einer gewissen Projektgröße) für unverzichtbar – und setzen so Projekte auf, die ähnlich gut geplant und verteilt werden wie die im Bauwesen.
Eines untermauert der Autor immer wieder mit seiner Formel: Der größte Erfolg stellt sich bei maximiertem Nutzen und minimiertem Aufwand ein. Und Letzteres lässt sich durch Code-Design und diverse Richtlinien günstig verändern – Thema etwa der Hälfte des Buchs. Drei Kardinalfehler benennt der Autor: das Schreiben von unnötigem Code, das Unterlassen, den Code änderbar zu gestalten, sowie zu generisch zu arbeiten.
Sodann zeigt er, wie man das umsetzen sollte – beziehungsweise eben nicht. Kurz, es geht darum, den Code einfach und damit wartbar zu halten. Das bedeutet, an manchen Stellen sogar auf Muster der objektorientierten Entwicklung zu verzichten. Was nutzt es, ein Programm so generisch zu halten, dass viele Teile künftig austauschbar sind, wenn diese Anforderung absehbar nicht vorhanden ist? Als Folge ist solcher Code oft schwer zu lesen. Unter Umständen wurden alle drei oben genannten Fehler auf einmal gemacht. Als Lösung schlägt Kanat-Alexander vor, den Code so einfach wie möglich zu halten – dabei gleichzeitig aber lesbar. Wer eine kompakte Darstellung liebt, erhält von diesem Buch wertvolle Tipps – vorausgesetzt, Werke wie "Clean Code" oder "The Art of Readable Code" sind unbekannt. (ane)
