Wir Softwareentwickler von der joocom haben vor einigen Wochen das Buch Der Pragmatische Programmierer von David Thomas und Andrew Hunt verschlungen. Es handelt sich dabei um ein Buch mit praxisnahen Tipps und Empfehlung, weit ab von konkreten Programmiersprachen oder Design Patterns. Ich möchte euch in diesem Blogpost mir einige Aspekte des Inhalts herauspicken und kurz beschreiben. Damit vielleicht jeder ein bisschen mehr anfängt pragmatisch zu denken.
Das Buch hat inhaltlich sehr viel zu bieten. Daher möchte ich nur auf die drei Dinge eingehen, die mir am meisten in Erinnerung geblieben sind.
Wiederholungen sind schlecht
Okay, Wiederholungen von alten Kultfilmen im Fernsehen sind vielleicht ab und zu nochmal ganz schön wieder anzusehen. Aber in der Softwareentwicklung möchte man keine Wiederholungen. Das gilt vor allem für den Quellcode. Man sollte gleiches niemals zweimal schreiben oder gar kopieren. Aber es gilt auch für andere Bereiche wie zum Beispiel die Dokumentation. Wenn man bereits an einer Stelle etwas gut dokumentiert hat, sollte man es nicht noch an einer anderen Stelle tun. Dann lieber die Dokumentation automatisch zum Beispiel aus dem Quellcode generieren lassen.
In der Softwareentwicklung nennt man dieses Vorgehen DRY - Don't Repeat Yourself.
Wiederholungen können entstehen wenn mehrere Entwickler an einem Projekt arbeiten und vielleicht nicht wissen, dass es eine Funktionalität schon an einer anderen Stelle gibt. Oder sie entstehen weil man sich als Entwickler dazu gezwungen fühlt oder zu ungeduldig ist, weil es einem schneller erscheint.
Automatisieren und Optimieren
Als Pragmatischer Programmierer sollte man immer bestrebt sein, sich die Arbeit so einfach wie möglich zu machen. Dazu gehört eine gute Entwicklungsumgebung zu benutzen, die einem bei seinem Handwerkszeug, dem Programmieren, bestmöglich unterstützt. Dazu gehört aber auch Vorgänge die man häufiger von Hand wiederholt zu automatisieren und manuelle Vorgänge zu vermeiden. Damit können der Buildprozess oder auch Verwaltungsdinge gemeint sein.
Fehler beheben
Es gibt keinen Grund schlechte Software zu entwickeln. Softwareentwickler sollten sich stets darum bemühen ihre Arbeit so gut wie möglich zu erledigen. Wenn einem beim Implementieren grobe Fehler oder schlechter Code auffällt sollte man ihn beheben. Schlechter Code führt sonst dazu das nach und nach weiterer schlechter Code hinzugefügt wird. Dies kann soweit gehen, dass eine Software irgendwann nicht mehr zu warten ist.
Im Buch wird die Theorie der zerbrochenen Fensterscheiben genannt. Dabei handelt es sich um ein Phänomen: Wenn ein Haus eine zerbrochene Fensterscheibe hat die nicht repariert wird, werden in schneller Zeit weitere Fensterscheiben zerbrochen, das Haus beschmiert, Müll liegen gelassen. In einem intakten Haus passiert dies nicht.
Daher gilt für einen pragmatischen Programmierer Fehler zu reparieren.
Fazit
Wir bei der joocom fanden das Buch genial und sprechen eine absolute Leseempfehlung aus!