Obwohl ich kein Spieleentwickler bin, habe ich mir dieses Buch gekauft, weil es von Dan Abramov empfohlen wurde (der ja auch kein Spieleentwickler ist). Es gibt einen guten Überblick über einen Haufen Design Patterns, die man auch allgemein mal anwenden kann, wenn man Lust drauf hat!
Der Beispielcode war (beinahe) komplett in C++, was mir natürlich nicht so viel bringt, und einige der Patterns sind vermutlich auch am nützlichsten, wenn man es mit einem sehr starren Object Oriented Type System zu tun hat, so dass man ständig Objekte in Objekte stecken muss, oder wenn es wirklich um jedes Milligramm Performance geht, so dass man ständig Linked Lists braucht und Memory Management machen muss.
Dieses Buch wurde mal von Gary Bernhardt empfohlen, und weil ich großes Vertrauen in ihn habe, habe ich es schließlich gekauft.
Es ist ein recht kurzes Buch, das sich mit einem Thema beschäftigt, das mir sehr am Herzen liegt: Wie schreibt man Software, die dauerhaft einfach und verständlich bleibt, obwohl man neue Features hinzufügt.
Im Prinzip habe ich dadurch wenig komplett Neues erfahren, weil es großteils Ideen sind, die ich schon mal gehört habe. Aber es ist auch mal schön, sie alle so gesammelt auf einem Haufen zu haben, zusammen mit guten Argumentationen für jede davon.
Irgendwann wurde dieses Buch irgendwo empfohlen. Ich habe es angeschafft und eigentlich ein paar amüsante Essays über Fehleinschätzungen bei Programmierprojekten erwartet. Mir war dabei nicht klar, dass dieses Buch aus dem Jahr 1975 ist.
Ich habe immerhin die erweiterte 20 Jahre Jubiläumsausgabe von 1995, die um ein paar Kapitel erweitert wurde, aber alle alten Kapitel wurden unverändert gedruckt. Die meiste Erfahrung von Brooks kommt von seiner leitenden Rolle bei der Entwicklung des IBM OS/360 (vorgestellt noch früher, nämlich 1964), und darum geht es auch hauptsächlich im Buch.
Und Leute, es war vielleicht noch nicht klar, aber 1975 ist so lange her, wenn es um Computer geht! 1975 gab es quasi keine Personal Computers, keine E-Mails (im Buch wird immer wieder empfohlen, man solle mit seinen Kollegen telefonieren!), keine Webseiten (im Buch gibt es eine Stelle, wo er beschreibt, dass das Handbuch während der Entwicklung des OS/360 mehrere Fuß breit war und sie irgendwann auf Mikrofilm umgestiegen sind, weil sonst jemand jeden Tag 150 neue Seiten Dokumentation einheften musste!), strukturiertes Programmieren mit Loops statt GOTO war noch umstritten, C war gerade brandneu (wurde aber im Buch nicht erwähnt). An einer Stelle erzählt er, wie sie durch schlechte Nutzung von Systemressourcen einen Compiler hatten, der fünf FORTRAN-Statements pro Minute kompiliert hat. ALTER.
Irgendwann habe ich mich damit abgefunden, dass das Buch eher ein historisches Dokument ist als etwas, das ich in meinem täglichen Leben anwenden kann – und von da an ging es eigentlich. Klar, ein paar Sachen kann man bestimmt mitnehmen oder hat man schon irgendwoanders gehört, aber als „modernen“ Überblick über Softwareentwicklung würde ich es nicht empfehlen.
Sidebar: Ja, ich weiß, es handelt sich hier literally um einen alten weißen Mann, aber ich schwöre, in diesem Buch kommt keine einzige Frau vor, außer, in der Widmung, seine Ehefrau Nancy. Alle Teams bestehen aus Männern, alle Chefs sind Männer, die Architekten sind Männer, einfach alle Arbeitskräfte sind Männer, die Mann-Tage und Mann-Monate und Mann-Jahre an Arbeit in etwas reinstecken.
Es fällt mir ein bisschen schwierig, dieses Buch zu bewerten.
Grundsätzlich handelt es davon, welche Eigenschaften und Gewohnheiten die beiden Autoren in sich selbst und anderen Softwareentwickler/innen sehen, die „Pragmatische Programmierer“ ausmachen. Ich halte mich selbst auch für pragmatisch, darum dachte ich, ich schaue mir dieses Buch mal an!
Mein Problem ist, dass das Buch halt, da kann man nicht drumherum reden, aus dem Jahr 2000 ist. An den Stellen, an denen es um allgemeine, übergreifende oder zwischenmenschliche (will sagen: zeitlose) Themen ging, war es interessant und gut.
Aber an den Stellen, an denen es darum ging, wie man Software, die vor 20 Jahren populär war, dazu benutzt, eine vor 20 Jahren populäre Programmiersprache besser zu benutzen, zog es sich ein bisschen. Wenn plötzlich empfohlen wird, dass man eine Makefile nutzen soll, um ein Perl-Script auszuführen, um damit wiederum eine Java-Klasse zu erstellen, dann muss ich mich doch fragen, ob es sich nicht langsam lohnen würde, eine aktualisierte Version dieses Buchs rauszubringen. (Außerdem haben sich die Best Practices in den letzten 20 Jahren hoffentlich etwas gebessert. (Das sage ich so einfach, aber wie oft arbeite ich auch heute noch in Teams, in denen es kein Testing und/oder keine Dokumentation gibt? Ständig. Also Nevermind.))
Und das ist es, was ich so schade finde: So viele der angesprochenen Themen sind auch heute noch gut und wichtig und Leute sollten von ihnen hören und sie anwenden: Orthoginality, Prototypes, Tracer Bullets, The Power of Plain Text, Refactoring, Testing, Automatisierung. Fuck yes! Aber ich weiß nicht, ob ich dieses Buch heute einfach so, ohne viele Fußnoten, einem Anfänger in die Hand geben würde – Ich müsste immer in Angst leben, morgen eine Makefile in meinem Node-Projekt zu haben oder dass sie plötzlich anfangen, die Programmiersprache Eiffel zu lernen – was im Buch mehrmals empfohlen wird!
Kann man ruhig immer mal wieder lesen, wenn man hin und wieder Webapps baut. (Oder, wenn man, wie ich, eigentlich nie was anderes macht.)
Teilweise merkt man dem Buch an, dass es von 2006 ist („Vergesst nicht, einen RSS-Feed einzubauen!“, „Bietet euren Nutzern ein Forum an, in dem sie sich austauschen können!“), aber die meisten Ratschläge sind zeitlos. Gefühlt setze ich auch die meisten Sachen bei meinen Projekten schon so um, wie sie im Buch empfohlen werden und bin damit auch sehr glücklich.
Manchmal war ich darum nicht sicher, ob sich aus den Tipps jetzt direkt eine Handlungsempfehlung für mich ableiten lässt, oder ob ich die schon umgesetzt habe. Wenn es zum Beispiel heißt, dass man darauf achten soll, Software zu schreiben, die weniger kann und einfacher geschrieben sein soll, frage ich mich: Kann ich meine Software reduzieren und vereinfachen, oder sind die Tipps an Leute gerichtet, die sonst Java Enterprise Applications schreiben, und mal probieren sollen, einen Server-Endpoint ohne fünf Factories zu bauen? Denn zum einen habe ich manchmal schon das Gefühl, vom Umfang meiner Projekte etwas überwältigt zu werden, auf der anderen Seite müssen auch Webapps ja irgendwas machen, und dafür muss halt häufig Code existieren?
Naja, ich melde mich wieder, wenn ich das Buch in einem Jahr oder so noch mal lese.
Das Spiel Spelunky fand ich immer schon spannend, ich bin aber noch nie dazu gekommen, es zu spielen. Stattdessen las ich jetzt also das Buch innerhalb eines Tages und es ist wunderbar.
Derek Yu hat einen ruhigen, entspannten Stil, nimmt einen mit durch die Entwicklung von Spelunky Classic und Spelunky HD und spricht bescheiden von seinen Spielen, die Millionen Mal heruntergeladen und gekauft wurden.
Matt Parker mag ich, seit mir eines schönen Tages der YouTube-Algorithmus ein Video von seinem Kanal vorgeschlagen hat.
In diesem Buch sind eine große Menge an Fehlern versammelt, die Menschen (und Computern – aber wer programmiert Computer? Eben.) passiert sind. Einige sind mit Todesfällen verbunden, aber viele sind harmlos und witzig – glücklicherweise gelingt Matt Parker hier eine gute Balance, so dass man sich nicht zu sehr runtergezogen fühlt. Die Beispiele sind vielseitig und gut ausgewählt, lustig erklärt, und ein paar Mal musste ich laut lachen.
Wenn man sich im weitesten Sinne für Mathematik, oder Computer, oder Fun Facts interessiert (und wer mag bitte keine Fun Facts?), dem kann ich das Buch sehr empfehlen.
Was mir übrigens an der Gestaltung des Buchs extrem gut gefallen hat: Die Seiten sind absteigend nummeriert! Die Seitenzahlen beginnen bei 312 und gehen dann langsam runter bis 1. Genial! Erst dachte ich, das wäre so ein halbwitziger Versuch, besonders neckisch zu sein aber inzwischen bin ich komplett überzeugt und hätte das gerne in allen Büchern. So gut!