Das Buch „Besser coden“:(https://www.rheinwerk-verlag.de/besser-coden_4405/ von Uwe Post erklärt, entgegen dem Titel, nicht wie man die Tätigkeit des Codens, also des Formulierens und Niederschreibens von Code, besser bewältigt. Keine Tipps wie man Krämpfe im Handgelenk und Unterarm vermeidet wenn man vorhat 36 Stunden am Stück zu programmieren. Keine Anleitung zu Editoren, Shortcuts und Macros. Keine Empfehlung zu Tastaturen und Sitzmöbeln. Stattdessen wird ein weitläufiger Bogen um allerlei Rahmenwerk geschlagen die Zusammenarbeit im Team und Softwarequalität betreffen. Das Buch sollte also besser heißen „Besserer Code“ statt „Besser Coden“.

Spaß beiseite! Das Buch von Uwe Post ist ein eingängiges Lesevergnügen für alle die Software entwickeln. Dank des luftigen, lockeren Schreibstils liest es sich recht schnell weg. Inhaltlich geht das Werk auf allerlei Techniken und Tools die in Java- und C#-Projekten die Entstehung einer Software unterstützen: Versionskontrolle, Projektmanagement, Teamkommunikation, Testing, Dokumentation, Continuous Integration. Vieles davon wird der Programmierer von Heute hoffentlich schon kennen. Für mich war das Buch allerdings nicht aufgrund seiner einzelnen Themen interessant sondern aufgrund der kompakten Auffrischung des gesamten Ökosystems das zur Entstehung von guter Software beiträgt.

Die eben beschriebenen Themen werden ergänzt durch „echte“ Programmierthemen wie Entwurfsmuster, Refactoring und Multithreading. Alles zusammen hat ganz klar seinen Schwerpunkt auf die Java-Welt. Für alle .NET-Fans wird auch noch auf die Eigenheiten dieser Plattform und deren Tools eingegangen. Für andere Umgebungen muss der Leser den Inhalt aber selber adaptieren.

Alles in allem bin ich sehr zufrieden mit dem Buch. Um allerdings noch etwas Kritik zu üben hier zwei Punkte: Bei manchen der Anmerkungen zu den eingestreuten Anekdoten viel es mir schwer zu entscheiden ob diese sarkastisch gemeint sind oder nicht – ein Nachteil der Schriftform. Bei der Vorstellung des Toolings zum Continous Integration wird für Java nur auf Jenkins eingegangen, im Gegensatz zu allen anderen Kapitel wo eigentlich immer auch eine Alternative besprochen wird. Ob dies daran liegt das Jenkins allem anderen Haushoch überlegen ist oder der Author keine Erfahrung über Jenkins hinaus aufweisen kann wird nicht klar.

Ich beziehe mich übrigens auf die gedruckte Version, zur Aufbereitung als eBook kann ich nichts sagen. Die Form (Zeilenabstand, Schriftgröße und so) ist, passend zum lockeren Schreibstil des Autors, recht luftig und leicht lesbar. In der Marginalspalte gibt es verstreut Stichwörter über den nebenstehenden Absätzen. Die hätte es meines Erachtens nicht benötigt, sie stören aber den Lesefluss nicht.