Gelesen: The Thoughtworks Anthology
Gelesen habe ich das Buch bereits im Mai, aber bis jetzt gezögert, darüber zu schreiben. Nicht weil es schlecht wäre, das nicht. Nun, das Buch kommt im typischen Gewand der No-Fluff-Just-Stuff-Serie, pro Kapitel schreibt ein Autor über ein Thema. Die Gemeinsamkeit der Autoren ist, dass sie alle bei Thoughtworks arbeiten, einer der laut Eigenaussage “most influential software companies” der Welt. Andere beschreiben das typische Verhalten Thoughtworks als “[..] you have a group of former C# and Java guys running around writing shitty Ruby code and training on the client’s dime for huge fees”.
Der Inhalt hört sich ganz gut an und ist es im Grossen und Ganzen eigentlich auch:
- Solving the Business Software “Last Mile”
- One Lair and Twenty Ruby DSLs
- The Lush Landscape of Languages
- Polyglot Programming
- Object Calisthenics
- What Is an Iteration Manager Anyway?
- Project Vital Signs
- Consumer-Driven Contracts: A Service Evolution Pattern
- Domain Annotations
- Refactoring Ant Build Files
- Single-Click Software Release
- Agile vs. Waterfall Testing for Enterprise Web Apps
- Pragmatic Performance Testing
Besonders interessant war das Kapitel Object Calisthenics, in dem ein paar fundamentale Regelnd festgelegt werden, die zu besserem OO-Design führen sollten, wenn man sich nur daran hält. Dazu gehört:
- Only one level of indentation per method.
- Don’t use the else keyword.
- Wrap all primitives and strings
- Use only one dot per line (Hey, erinnert mich an Demeter’s Law).
- …
- Don’t use and getters/setters/properties
Wer wissen will, was all die Regeln genau sollen, muss sich das Buch wohl kaufen oder mal bei mir ausleihen. Aber eigentlich sollte man auch von selbst darauf kommen.
Nun, wer die No-Fluff-Just-Stuff-Bücher gerne gelesen hat, wird sich auch über dieses hier freuen.
2 comments on “Gelesen: The Thoughtworks Anthology”
Leave a comment
You must be connected to write a comment.
Hehe, witzig: Wir haben das mit den Object Calisthenics in der FIrma auch grad in die Finger bekommen und in kleinen 2-3 Mann Grüppchen das mal zwei Tage lang an einem kleinen Beispielprojekt ausprobiert.
Ist schon sehr witzig, obwohl ich eigentlich sehr wenig von solch starren Regeln halte. Aber es zwingt einen, sehr viel mehr über den Code nachzudenken und wenn man die Modell-Klassen ersteinmal entsprechen strukturiert hat, dann baut man Erweiterungen meist “automatisch” an der richtigen Stelle ein, d.h. da wo es sich auch immer direkt “gut anfühlt”. Allerdings muss man sich ersteinmal daran gewöhnen, dass man doch deutlich mehr Zeit braucht, weil man halt viel mehr nachdenken muss und immer mal wieder umbaut. Wir haben dass dann häufig auch so Pair-Programming mäßig gemacht, was dann auch zu teilw. längeren Diskussionen führt, warum etwas in diese Klasse kommt und nicht in jene.
Ist aber eine sehr interessante Erfahrung, ich habe auch direkt dann in unserem “richtigen” Projekt an einigen Stellen etwas davon angewandt und fühlte mich gut dabei
Was für ein Zufall
Aber wundert mich ehrlich gesagt nicht besonder bei deiner Firma.. ist die einzige Präsentation der SE die mir mehr oder weniger in Erinnerung geblieben ist.
Dann muss ich das wirklich auch mal genau so ausprobieren..