Ich habe Mark Seemanns Buch “Code that Fits in your Head” gelesen und fand das Buch lesenswert. Mark Seemann immer den (für mich) nötigen Kontext mitliefert und orthodoxe Regeln (z. B. die Regel “keine Tests von internen Methoden”) in Frage stellt, wenn es Sinn macht. Das Buch ist sicher kein direktes Einsteigerbuch, weil es einen Überflug über viele Themen liefert und auch spannende Gedanken platziert, ohne das Grundwissen in den verschiedenen Themen.

In den ersten Kapiteln wird die Motivation hergeleitet, warum es wichtig ist, dass Code “in den Kopf passen muss”. Dabei stellt er zuerst die Frage, ob Softwareentwickluhng Kunst oder Wissenschaft ist (letztlich wohl beides). Danach kommt ein praktischer Teil, der sich auf das Programmieren selbst bezieht, bevor es danach in einigen Kapiteln um Arbeitsorganisation und Teamarbeit geht.

Etwas schwierig fand ich, dass die Kapitelüberschriften teilweise erst im Nachhinein Sinn ergaben. Zum Beispiel in Kapitel 5 mit dem Titel “Encapsulation” macht er einen Ausflug zu Red, Green, Refactor und der Analogie, dass es für Softwareentwicklung kaum wissenschaftlicher/ Ingenieursmäßiger geht (erst die Hypothese aufstellen, um sie dann zu überprüfen). Das hat aber mit dem eigentlichen Thema der Datenkapselung wenig zu tun. Die Kapselung wird erst auf den letzten Seiten des Kapitels vollständig erklärt. Der Autor macht das, weil er den Nutzen der Kapselung herleiten will, aber für den Leser fehlt dazu im ersten Moment der rote Faden. Ein ähnliches Beispiel ist das Kapitel “Triangulation” - wenn man das Bild einmal versteht, macht es Sinn, aber der Weg dorthin ist etwas steinig.

Mark Seemann lässt seine Leser in dem Buch auch an seinen Gedanken teilhaben, wenn er keine Lösung findet. Ein Beispiel bei dem er auch keine Lösung hat, ist das Wissen, wie man sinnvoll Wissen über die API erlangen kann. Er gibt mehrere Beispiele, an denen er bessere Code-Beispiele gibt und sich selbst die Frage stellt, wie man das herleiten könnte. Beispielsweise, dass TryParse() Methoden Parsen versuchen und bei Misserfolg direkt False zurückgeben oder dass man bei LINQ direkt die Methode Sum() verwenden kann. Die ganze .net API auswendiglernen ist da sicher keine Lösung. Er schreibt dazu “I never promised that the art of software engineeering would be an altogether deterministic process.” Aber ist es so einfach? Ist es für neue Entwickler nicht gerade wirklich so, dass man mit der Suche nach Summe über ein Listenelement eine Antwort finden kann? Auch bei den “echten” Ingenieuren gibt es vermutlich Lösungen, die aber aus Sicht erfahrener Ingenieure umständlich sind und durch elegantere Lösungen ersetzt werden. Auch hier wird das Wissen über die beste Lösung nicht als Kanon weitergegeben und falls doch, wäre dieser Kanon vermutlich genau so unübersichtlich wie die .net API.

Zwei meiner persönlichen Learnings aus dem Buch waren, dass ich mich zu mehr Pausen beim Coden zwingen muss, um den Tunnelblick zu vermeiden und dass ich das Dekoratorpattern fürs Logging z . B. bei Repositories verwenden möchte. Für letzteres hat er im Buch ein schönes Beispie, für ersteres gibt es diesen Blogartikel. Das waren aber nur zwei Beispiele, die Liste meiner Notizen zu dem Buch ist deutlich länger.