Wer noch keinen Verwendungszweck fuer seine weihnachtlichen Buch-Gutscheine gefunden hat, kann hier einmal reinschauen.

[amazon-product align="center" type="image" image="51TG9F1B8AL._SL500_AA240_.jpg"]0131177052[/amazon-product]

[amazon-product align="center" type="image" image="http://ecx.images-amazon.com/images/I/418-XemgPzL._SL500_AA240_.jpg"]3826690214[/amazon-product]

Das English sprachige Original [amazon-product type="text" text="Working Effectively with Legacy Code (Robert C Martin)"]0131177052[/amazon-product] oder ab April die Deutsche Variante [amazon-product type="text" text="Arbeiten mit Legacy Code: Wartung und Pflege alter Software-Systeme"]3826690214[/amazon-product] von Michael C. Feathers.

Ich habe das Buch seit ein drei Wochen zuhause und muss sagen, es ist super!
Es geht dabei nicht um die graue Theorie oder irgendwelche Ideale sondern um kontinuierliche Verbesserung waerend der taeglichen Arbeit und alles im Bereich des Moeglichen. Sehr pragmatisch und hands-on.

Hier mal die Inhaltsangabe. Allein aus der kann man sehen, wie pragmatisch – weil Problem orientiert – die Ansaetze sind.
Und die Kapitelueberschriften 6-24 sollten uns ja allen bestens bekannt vorkommen oder?

I. THE MECHANICS OF CHANGE.
1. Changing Software.
2. Working with Feedback.
3. Sensing and Separation.
4. The Seam Model.
5. Tools.

II. CHANGING SOFTWARE.
6. I Don’t Have Much Time and I Have To Change It.
7. It Takes Forever To Make a Change.
8. How Do I Add a Feature?
9. I Can’t Get This Class into a Test Harness.
10. I Can’t Run This Method into a Test Harness.
11. I Need to Make a Change. What Methods Should I Test?
12. I Need to Make Many Changes In One Area Do I Have To Break.
13. I Need To Make a Change but I Don’t Know What Tests To Write.
14. Dependencies on Libraries Are Killing Me.
15. My Application Is All API Calls.
16. I Don’t Understand the Code Well Enough To Change It.
17. My Application Has No Structure.
18. My Test Code Is in the Way.
19. My Project Is Not Object-Oriented. How Do I Make Safe Changes?
20. This Class Is Too Big and I Don’t Want It to Get Any Bigger.
21. I’m Changing The Same Code All Over the Place.
22. I Need To Change a Monster Method and I Can’t Write Tests for It.
23. How Do I Know That I’m Not Breaking Anything?
24. We Feel Overwhelmed. It Isn’t Going To Get Any Better.

III. DEPENDENCY BREAKING TECHNIQUES.
25. Dependency Breaking Techniques.

Das Buch konkurriert auf den ersten Blick mit Martin Fowlers [amazon-product type="text" text="Refactoring: Improving the Design of Existing Code (Object Technology Series)"]0201485672[/amazon-product] (auf Deutsch [amazon-product type="text" text="Refactoring. Wie Sie das Design vorhandener Software verbessern"]3827316308[/amazon-product]). Bei näherer Betrachtung jedoch erweist sich das als falsch. Das Buch ist viel mehr eine Ergänzung.

Wo Standardwerke wie das von Fowler eher akademisch an die Thematik herangehen und sich an einem Bild idealer Software orientieren, konzentriert sich Martin C. Feathers Buch auf den vorhandenen zumeist wenig idealen Code und zeigt Wege auf, wie der Entwickler während der täglichen Arbeit die Qualität des vorliegenden Codes kontinuierlich steigern kann. Es geht eben nicht darum, alleine den Code zu refactoren, sondern darum seine täglichen Aufgaben sicher und korrekt umzusetzen. Kaum ein Entwickler wird die nötige Zeit bekommen nur um die Code Qualität zu verbessern, seine Aufgaben sind Bugfixes, neue Features und Änderungen. Wie man diese Arbeiten sauber umsetzt und währendessen die Qualität des Codes steigert, dafür liefert das Buch viele prakmatische und vor allem Praxis relevante Ansätze.

Working Effectively with Legacy Code ist ein Buch, welches nie weit vom Arbeitsplatz entfernt liegen sollte.
Refactoring von Martin Fowler sollte man aber natürlich nicht viel weiter wegliegen haben.

Dringende Kaufempfehlung!

Legacy Code · Michael C. Feathers · Refactoring · Robert C. Martin · Test Driven Development

<< Testen einer symfony Applikation

Gehostete Continuous Integration Services? >>