Code That Fits in Your Head Heuristiken für die Softwareentwicklung. Komplexität reduzieren | Legacy Code beherrschen | Performance optimieren

Ich habe verstanden, dass das Buch eine Sammlung von Vorgehensweisen sein soll, die sich über viele Jahre für den Autor bewährt haben. Vielen seiner Empfehlungen würde ich allerdings widersprechen, weil ich sie aus meiner (ebenfalls langen) Erfahrung für gar nicht gut halte. Auch wenn er immer wieder betont, dass diese Dinge für ihn gut funktionieren und er diese nicht als "Gesetz" verstanden haben möchte, sind sie in meinen Augen eben nicht empfehlenswert. Ein Beispiel, am den sich das in der Kürze einer Rezension gut zeigen lässt: Im Buch findet sich die Aussage "Kümmere dich erst um eine funktionierende Software und erst später um Performance". Als Beispiel führt er ein Erlebnis aus seinem Beratungsalltag an, bei dem seine funktionierende Software abgelehnt wurde, weil sie langsamer als die bestehende (aber nicht korrekt funktionierende) Software war. Natürlich ist, wenn es nur ein entweder oder gibt, die Korrektheit einer Software wichtiger als eine hohe Performance, aber die Performance nicht von Beginn an mitzudenken, bedeutet oft entweder, dass sie am Ende zwar korrekt funktioniert, aber so langsam ist, dass sie in der Praxis quasi nicht nutzbar ist oder dass man u.U. viel Aufwand in ein Refactoring stecken muss. Vielleicht gut für den Umsatz, aber in meinen Augen eben keine gute Vorgehensweise. Wie beim Autor bzw. im Buch der fehlende Fokus auf die Performance dann mit einem der Untertitel des Buches, nämlich "Performance optimieren", zusammenpasst, hat sich mir dann erst recht nicht erschlossen. So gesehen, verspricht der Titel etwas, was das Buch nicht hält. (Vielleicht sind mit Performance hier auch gewollt zwei verschiedene Dinge gemeint, was dann aber nur zeigen würde, wie wichtig die passende Benennung ist, was in dem Buch aber überhaupt keine Rolle spielt, was ich wiederum für wichtig halte.) Es gibt andere Aspekte, die ich ähnlich beurteile, diese auszuführen, würden hier aber zu weit führen. Ein weiterer, wesentlicher Punkt, der mir an dem Buch nicht gefällt, ist, dass es sehr ausschweifend ist. Es gibt viel (allgemeinen) Text, Anekdoten u.Ä. Vielleicht war der Autor der Meinung, dass er dadurch seine Sichtweise besser darlegen und begründen kann. (Die weniger schmeichelhafte Auslegung wäre, dass er irgendwie die Seiten füllen wollte/musste.) Ich weiß es nicht. Für mich war es aber nicht hilfreich, mich durch den Text und Code zu kämpfen, um seine Aussage zu erkennen. (Dass er damit gegen seine eigene "halte es knapp und kurz"-Empfehlung verstößt, entbehrt nicht einer gewissen Ironie, auch wenn Code schreiben und ein Buch schreiben zwei verschiedene Dinge sind.) Egal, wie man zu seine Aussagen und Empfehlungen steht, diese würden vermutlich auf einen Bruchteil der Seiten passen. Kurz: Auch wenn ich durchaus manchen seiner Punkte zustimme und man andere vielleicht nur diskutabel findet, ist das Buch in meinen Augen insgesamt zu schlecht, um es jemand zu empfehlen, der damit ein besserer Entwickler werden möchte.