Der Pragmatische Programmierer [Taschenbuch]

Das Buch an sich ist unabhängig von der verwendeten Programmiersprache und der Programmiermethodik, obwohl man ganz klar die Präferenzen der Autoren für XP und OO Programmierung mit C++ oder Java erkennen kann. An ein paar Stellen werden ein paar Details zu Implementierungen eingestreut (z.B. wusste ich nicht, dass der ddd auch Perl Programme debuggen kann [Beispiel für ein Orthogonales Design]). Es gibt keine hochtrabenden Empfehlungen diese oder jene hochtrabende Methode zu verwenden, sondern es werden klare, einleuchtende und z.T. einfache Empfehlungen präsentiert wie z.B. "Verwenden Sie immer Versionskontrolle".

Das Buch besteht aus 70 Ratschlägen in 8 Kapiteln, zwei Anhängen und einer Zusammenfassungseinlage in der Mitte. Nicht nur die Tipps (in der Langversion im Text und in der Kurzversion in der Zusammenfassung) sondern auch die Anhänge sind ihr Geld mehr als Wert. Mir hat der Anhang A (Quellen / Literaturverzeichnis) besonders gut gefallen (zusätzlich zum Text). Im Anhang A wird kurz die verwendetet Literatur besprochen. Zu jeder Quelle wird eine kurze Inhaltsangabe gegeben (gut als Hinweis für weitere Bücherkäufe :-). Zusätzlich werden noch eine Reihe von sehr informativen Internet Adressen aufgelistet.

Ein paar von den Tipps sind meiner Meinung nach recht schwer umzusetzen (z.B. Design by Contracts) oder sehr aufwendig (z.B. konfigurieren Sie, statt zu integrieren), was diese Tipps aber nicht weniger sinnvoll macht. Eigentlich sollte man als Programmierer zumindest einen großen Teil dieser Tipps schon immer befolgt haben (oder haben wir uns nicht alle schon um eine Reihe dieser Tipps herumgedrückt ;-). Die meisten dieser Ratschläge sind nicht wirklich neu. Die Zusammenstellung (aus vielen Quellen), die Formulierung und die Argumentation dieser Tipps in der vorliegenden Form, machen das Buch zu einem echten Highlight.

Im pragmatischen Programmierer sind viele "goldige" Details versteckt, die mir sehr gefallen z.B. bei Abschätzungen (Seite 60) sollte man die Granularität in Ergebnisse (nicht immer Tage, sondern Wochen oder Monate verwenden) von der Höhe des Ergebnisses abhängig machen und (besonders gut) besser keine Abschätzungen für Dinge über 30 Wochen Aufwand abgeben. Die Autoren haben verstanden das Projektgeschäft nicht nur Technologie sondern auch Psychologie ist.

Als Datenbank Mensch hat mir nicht so gut gefallen, dass die Autoren immer davon ausgehen, dass man "mal eben" die Datenbank wechseln kann (bei guter Kapselung). Ich bin nicht dieser Meinung, da man mit einem solchen Vorgehen nicht das Optimum des jeweiligen Datenbank Systems (für das man viel Geld bezahlt hat) nutzen wird.

Ich habe vor Jahren das englische Original zu diesem Buch gelesen und ich finde die Übersetzung und die Anmerkungen der Übersetzer im Vorwort unter "Do you speak English" sehr gut und sehr gelungen. Man merkt sofort, dass Fachleute übersetzt haben, die das Thema kennen und das Buch selbst für sehr gut halten.

Wenn man gute Ratschläge für jeden Programmierer sucht ohne Methoden Overhead bzw. Methoden Verklärung der Tatsachen, sollte man dieses Buch kaufen. Man wird diesen Kauf als pragmatischer Programmierer nie bereuen.

Zu diesem Buch kann ich - als Ergänzung - alle Bücher von DeMarco (z.B. Bärentango) sehr empfehlen.

Zu den Tipps selber, hier meine persönlichen Highlight-Stichworte (also das, was ich selbst für besonders wichtig halte): Abgesichertes Programmieren/Assertions, Design-by-Contract, Klartext statt Binärcodes, Entwickeln für den Test/Unittests, schonungsloses Testen, Regelmäßige Code-Überarbeitung/Refaktorisierung, Entkopplung von Komponenten, Maschinelle automatisierung statt fehleranfällige Routinearbeiten/Quelltextgeneratore, Entkopplung von Oberfläche und Backend (Model-View-Controller Design).