David Thomas
Andrew Hunt

Der Pragmatische Programmierer

Ihr Weg zur Meisterschaft

Jubiläumsausgabe

übersetzt von Jürgen Dubau

Ich weiß noch, als Dave und Andy das erste Mal über die Neuauflage dieses Buchs twitterten. Das war eine große Meldung. Ich sah zu, wie die Entwicklerwelt mit Begeisterung reagierte. Mein Feed kam gar nicht zur Ruhe. Nach zwanzig Jahren ist Der Pragmatische Programmierer heute genauso relevant wie damals.

Es sagt viel aus, dass ein Buch mit einer solchen Geschichte solch eine Reaktion bewirkt. Ich hatte das Privileg, für dieses Vorwort ein unveröffentlichtes Exemplar zu lesen, und ich verstand, warum es solches Aufsehen erregte. Es ist zwar ein technisches Buch, aber es als solches zu bezeichnen, erweist ihm einen schlechten Dienst. Technische Bücher schüchtern oft ein. Sie sind vollgestopft mit großen Worten, obskuren Begriffen, überfrachteten Beispielen, bei denen man sich unabsichtlich dumm fühlt. Je erfahrener ein Autor ist, desto leichter vergisst er, wie es ist, neue Konzepte zu lernen oder ein Anfänger zu sein.

Trotz ihrer jahrzehntelangen Programmiererfahrung haben Dave und Andy die schwierige Herausforderung des Schreibens mit der gleichen Begeisterung gemeistert wie Menschen, die diese Lektionen gerade erst gelernt haben. Sie reden nicht von oben herab mit Ihnen. Sie setzen nicht voraus, dass Sie Experte sind. Sie gehen nicht einmal davon aus, dass Sie die erste Ausgabe gelesen haben. Sie nehmen Sie so, wie Sie sind: als Programmierer, die einfach nur besser werden wollen. Dazu haben sie dieses Buch verfasst, um Ihnen dabei zu helfen, dorthin zu gelangen, jeweils einen machbaren Schritt nach dem nächsten.

Fairerweise muss man sagen, dass sie dies bereits vorher gemacht hatten. Die ursprüngliche Veröffentlichung war voller konkreter Beispiele, neuer Ideen und praktischer Tipps zum Aufbau Ihrer Entwickler-Muskeln und zur Entwicklung Ihres Entwickler-Hirns, die auch heute noch gelten. Aber in dieser aktualisierten Ausgabe werden zwei Sachen verbessert.

Die erste ist offensichtlich: Einige ältere Verweise oder veraltete Beispiele entfallen und werden durch neue, moderne Inhalte ersetzt. Sie werden keine Beispiele für Schleifeninvarianten oder Build Machines finden. Dave und Andy sorgen mit ihren eindringlichen Inhalten dafür, dass die Lektionen immer noch wirksam sind und es keine Ablenkung durch veraltete Beispiele gibt. Hier werden alte Ideen wie DRY (Don’t Repeat Yourself, dt. „Wiederholen Sie sich nicht“) entstaubt und bekommen einen frischen Anstrich, der sie wirklich zum Glänzen bringt.

Aber die zweite Sache macht diese Veröffentlichung wirklich spannend. Nach der ersten Ausgabe hatten beide Gelegenheit, darüber nachzudenken, was sie zu sagen versuchten, was sie ihren Lesern mitgeben wollten und wie das aufgenommen wurde. Sie erhielten Rückmeldungen zu diesen Lektionen. So konnten sie erkennen, wo es knirschte, was verfeinert werden musste, was missverstanden wurde. In den zwanzig Jahren, in denen dieses Buch seinen Weg durch Hände und Herzen von Programmierern auf der ganzen Welt gefunden hat, studierten Dave und Andy diese Reaktionen und formulierten neue Ideen und neue Konzepte.

Sie haben die Bedeutung der Handlungsfähigkeit kennengelernt und erkannt, dass Entwickler vermutlich mehr davon besitzen als die meisten anderen Fachleute. Sie beginnen dieses Buch mit der einfachen und doch tiefgründigen Botschaft: „Es ist Ihr Leben.” Das erinnert uns an unsere Macht bei unserer Code-Basis, in unseren Jobs, in unseren Karrieren. Es gibt den Ton für alles andere im Buch an – dass es mehr ist als nur ein weiteres technisches Buch voller Code-Beispiele.

Dieses Buch sticht wirklich aus den Regalen der Fachbücher heraus, weil hier Leute verstehen, was es bedeutet, ein Programmierer zu sein. Bei der Programmierung geht es darum, zu versuchen, die Zukunft weniger schmerzhaft zu gestalten. Es geht darum, Dinge für unsere Teamkollegen einfacher zu machen. Es geht darum, Fehler zu machen und wieder auf die Beine zu kommen. Es geht darum, gute Gewohnheiten zu etablieren. Es geht darum, die eigenen Instrumente zu verstehen. Coding ist nur ein Teil der Welt des Programmiererdaseins und dieses Buch untersucht diese Welt.

Ich verbringe viel Zeit damit, über diese Reise als Entwickler nachzudenken. Mit Coding bin ich nicht aufgewachsen, habe es nicht am College studiert. Ich habe meine Teenagerjahre nicht damit verbracht, an der Technik herumzubasteln. Ich bin mit Mitte zwanzig in die Welt der Programmierung eingetreten und musste lernen, was es heißt, Programmierer zu sein. Diese Gemeinschaft unterscheidet sich sehr von anderen, denen ich angehörte. Hier engagiert man sich auf einzigartige Weise für das Lernen und die praktische Anwendung, die sowohl erfrischend als auch einschüchternd ist.

Für mich war es, als würde ich in eine neue Stadt ziehen. Ich musste die Nachbarn kennen-lernen, Geschäfte suchen, die besten Cafés finden. Es dauerte, bis mir die Gegend vertraut war und ich die effizientesten Routen kannte, Straßen mit hohem Verkehrsaufkommen vermeiden konnte und wusste, wann die Rush Hour ist. Für das andere Wetter brauchte ich auch neue Klamotten.

Die erste Zeit in einer neuen Stadt kann beängstigend sein. Wie schön, freundliche, sachkundige Nachbarn zu haben, die dort schon eine Weile leben? Wer zeigt einem die Nachbarschaft mit den Cafés und so? Jemand, der Kultur und Puls der Stadt versteht, sodass man sich nicht nur zu Hause fühlt, sondern zur Gemeinschaft beiträgt? Dave und Andy sind solche Nachbarn.

Als relativer Neuling wird man leicht überwältigt – nicht vom Akt des Programmierens, sondern von dem Prozess, ein Programmierer zu werden. Hier muss ein kompletter Mentalitätswandel stattfinden – Gewohnheiten, Verhaltensweisen und Erwartungen müssen sich ändern. Der Prozess, ein besserer Programmierer zu werden, geschieht nicht nur, weil man gelernt hat, wie man programmiert; er muss mit Absicht und bewusster Praxis durchgeführt werden. Dieses Buch ist eine Handreichung, damit Sie ein besserer Programmierer, eine bessere Programmiererin werden.

Aber täuschen Sie sich nicht – es sagt Ihnen nicht, wie Entwickeln geht. Es ist nicht in dieser Weise philosophisch oder wertend. Hier erfahren Sie schlicht und einfach, was Pragmatische Programmierer sind, wie sie arbeiten und wie sie an Code herangehen. Die Autoren überlassen es Ihnen zu entscheiden, ob Sie einer werden wollen. Wenn Sie das Gefühl haben, dass das nichts für Sie ist, werden sie es Ihnen nicht übelnehmen. Aber wenn Sie entscheiden, dass dies Ihr Weg ist, sind das freundliche Nachbarn, die Ihnen den Weg zeigen.

Saron Jitbarek

Gründer und CEO von CodeNewbie

Host von Command Line Heroes

In den 1990er-Jahren arbeiteten wir mit Unternehmen, deren Projekte Probleme bereiteten. Wir ertappten uns dabei, wie wir jedem das Gleiche sagten: Vielleicht sollten Sie das testen, bevor Sie es ausliefern? Warum geht der Build für diesen Code nur auf dem Rechner von Maria? Warum hat niemand die Anwender gefragt?

Um bei neuen Kunden Zeit zu sparen, begannen wir mit unseren Notizen. Und aus diesen Notizen wurde Der Pragmatische Programmierer. Zu unserer Überraschung schien das Buch den Nerv der Zeit zu treffen und es ist in den letzten 20 Jahren nach wie vor beliebt.

Aber 20 Jahre sind in Bezug auf Software viele Lebensalter. Nehmen Sie einen Entwickler von 1999 und setzen Sie ihn heute in ein Team und er würde sich sehr abkämpfen, in dieser fremden neuen Welt klarzukommen. Aber die Welt der 1990er-Jahre ist dem heutigen Entwickler ebenso fremd. Die Verweise des Buchs auf Dinge wie CORBA, CASE-Tools und indexbasierte Schleifen waren bestenfalls kurios und wahrscheinlich eher verwirrend.

Gleichzeitig haben 20 Jahre keinerlei Auswirkungen auf den gesunden Menschenverstand gehabt. Die Technologie mag sich geändert haben, aber die Menschen eben nicht. Praktiken und Ansätze, die damals eine gute Idee waren, sind auch heute noch gut. Diese Aspekte des Buchs sind gut gealtert.

Als es also an der Zeit war, zum 20. Jahrestag diese Ausgabe zu erstellen, mussten wir eine Entscheidung treffen. Wir könnten die Technologien, auf die wir verweisen, durchgehen, aktualisieren und dann Feierabend machen. Oder wir könnten die Annahmen, die den von uns empfohlenen Praktiken zugrunde liegen, im Lichte weiterer zwei Jahrzehnte Erfahrung noch einmal überprüfen.

Am Ende haben wir beides getan.

Daher ist dieses Buch so etwas wie ein Schiff des Theseus.¹ Etwa ein Drittel der Themen in diesem Buch sind brandneu. Von den übrigen wurden die meisten teilweise oder vollständig umgeschrieben. Unsere Absicht war es, die Dinge klarer, relevanter und hoffentlich etwas zeitloser zu machen.

Wir mussten einige schwierige Entscheidungen treffen. Wir haben den „Ressourcen“-Anhang weggelassen, sowohl weil es unmöglich wäre, auf dem neuesten Stand zu bleiben, als auch weil es einfacher ist, das Gewünschte zu finden. Angesichts des derzeitigen Überflusses an parallel arbeitender Hardware und des Mangels an guten Möglichkeiten, damit umzugehen, haben wir Themen im Zusammenhang mit Concurrency neu organisiert und verfasst. Ergänzt wird das durch Inhalte, die die sich verändernden Einstellungen und Umgebungen reflektieren: von der agilen Bewegung, die wir mit ins Leben gerufen haben, über eine steigende Akzeptanz funktionaler Programmiersprachen bis hin zum wachsenden Bedürfnis nach Berücksichtigung von Privatsphäre und Sicherheit.

Interessanterweise gab es zwischen uns jedoch wesentlich weniger Diskussionen über den Inhalt dieser Ausgabe als beim Verfassen der ersten. Wir waren beide der Meinung, dass die wichtigen Sachen leichter zu erkennen sind.

Das Buch, das Sie in Händen halten, ist jedenfalls das Ergebnis. Bitte genießen Sie es. Vielleicht eignen Sie sich ein paar neue Praktiken an. Vielleicht beschließen Sie, dass einige der von uns vorgeschlagenen Dinge falsch sind. Lassen Sie sich auf Ihr Handwerk ein. Sagen Sie uns Ihre Meinung.

Denken Sie aber vor allem daran, dass es Spaß machen soll.

Aufbau des Buchs

Dieses Buch ist mehr als eine Sammlung von Tipps. Jedes Thema ist in sich abgeschlossen und behandelt einen bestimmten Aspekt. Zahlreiche Querverweise sollen helfen, jedes Thema in Zusammenhänge einzuordnen. Sie können das Buch mit seinen Topics in beliebiger Reihenfolge lesen.

Gelegentlich werden Sie auf einen Kasten mit der Beschriftung Tipp n stoßen (so wie Tipp 1, Kümmern Sie sich um Ihr Können). Tipps betonen einerseits entscheidende Stellen im Text, andererseits sind sie auch für sich alleine gültig – wir selbst wenden sie täglich an. Eine Zusammenfassung aller Tipps finden Sie auf dem Beihefter im Buch.

An geeigneten Stellen haben wir Übungen und weiterführende Aufgaben eingefügt. Während die Übungen relativ einfache Lösungen haben, sind die Aufgaben ziemlich offen gestellt. Um Ihnen eine Vorstellung von unserer Denkweise zu geben, haben wir unsere Lösungen zu den Übungen im Anhang zusammengetragen. Nur wenige Übungen haben eine einzige richtige Lösung. Die Aufgaben sind eher als Grundlage für Diskussionen oder Ausarbeitungen in Programmierkursen für Fortgeschrittene gedacht.

Am Ende finden Sie auch eine kurze Bibliografie, in der die Bücher und Artikel aufgeführt sind, auf die wir ausdrücklich verweisen.

Schall und Rauch

„Wenn ich ein Wort gebrauche“, sagte Humpty Dumpty in leicht verächtlichem Ton, „so bedeutet es das, was ich will, dass es bedeutet – nicht mehr und nicht weniger.“

Lewis Carroll, „Alice hinter den Spiegeln“

Quer über das Buch verteilt finden sich Fachjargonschnipsel – entweder vollkommen vernünftige Wörter, die für eine technische Bedeutung missbraucht wurden, oder schreckliche Wortschöpfungen, denen von Informatikern ohne Gefühl für Sprache eine Bedeutung zugewiesen wurde. Wir versuchen, solche Fachbegriffe zu definieren oder zumindest ihre Bedeutung zu beschreiben, wenn wir sie zum ersten Mal verwenden. Dennoch sind uns sicher einige durch die Lappen gegangen und andere wie Objekt und Relationale Datenbank sind so gebräuchlich, dass eine Definition nur langweilen würde. Wenn Sie auf ein unbekanntes Wort stoßen, überspringen Sie es bitte nicht. Nehmen Sie sich die Zeit, es im Internet oder einem Informatiklehrbuch nachzuschlagen, und schicken Sie uns eine E-Mail, damit wir in der nächsten Auflage eine Definition angeben können.

Wir haben uns entschieden, Rache an den Informatikern zu nehmen. Manchmal gibt es durchaus gute Fachwörter für Konzepte, doch wir haben beschlossen, diese Wörter zu ignorieren. Warum? Weil der vorhandene Fachjargon in der Regel auf einen bestimmten Problembereich oder auf eine bestimmte Entwicklungsphase beschränkt ist. Eine der Grundphilosophien dieses Buchs ist jedoch, dass die meisten von uns vorgeschlagenen Techniken universell sind: Modularität zum Beispiel betrifft Quelltext, Entwurf und Teamorganisation. Wenn wir gebräuchliche Fachwörter in einem breiteren Kontext verwenden wollten, erschien es verwirrend, und wir konnten den ganzen Ballast der ursprünglichen Bedeutung nicht loswerden. In diesen Fällen haben wir zum Verfall der Sprache beigetragen und unsere eigenen Wörter erfunden.

Quelltexte und andere Quellen

Die meisten Beispiele in diesem Buch sind kompilierbaren Quelltexten entnommen, die Sie von der Plus.Hanser-Webseite herunterladen können: