Saturday, August 07, 2010

Growing Object-Oriented Software (GOOS)

Nachdem ich mein letztes Buch (Softwaretests mit JUnit von Johannes Link) fertiggelesen habe und von der Materie einfach nur begeistert und überzeugt bin, habe ich beschlossen ein weiteres Buch, dass sich mit dem Thema TDD beschäftigt, zu lesen. Nur welches? Es gibt so extrem viele, die ich alle noch unbedingt lesen möchte, allerdings hat sich eines davon ganz klar abgesetzt, nämlich: “Growing Object-Oriented Software, Guided by Tests

So ziemlich jeder meiner Entwickler-Vorbilder, haben dieses Buch empfohlen. Man solle es allerdings nicht nur lesen, sondern die Vorgehensweisen der Autoren wirklich nachvollziehen und verstehen. Michael Feathers spricht von “Sate of the Art TDD”, Robert C. Martin sagt “This one’s a keeper” und noch einige mehr sind davon überzeugt, dass das Lesen und Verstehen dieses Buchs die eigenen Entwicklerfähigkeiten auf ein anderes Niveau anheben wird.

Fragen

Dieser Blog-Post soll keine Zusammenfassung des kompletten Buchs werden, sondern vielmehr einer von vielen, die meine Gedanken bezüglich der einzelnen Kapitel wiedergeben. Ich bin ja schon seit einiger Zeit überzeugter “TDDler” und doch stellen sich mir immer wieder Fragen wie z.B.:

  • Wie baut man ein größeres verteiltes System mittels TDD?
  • Wie viel wird vorab Designed?
  • Was bedeutet eigentlich die Phrase: “Die Tests treiben meine Entwicklung”?
  • Wie und wo fängt man eigentlich an?
  • Wie behält man bei einer großen Anzahl von Tests die Übersicht?
  • Wann ist man fertig?

Natürlich werden noch weitere Fragen auftauchen und hoffentlich mit Hilfe dieses Buchs beantwortet werden. Mittlerweile habe ich das erste Kapitel “What is the point of TDD?” fertiggelesen und bin begeistert. Es konnten schon einiger meiner Fragen zum Teil beantwortet werden. Wie in jedem von mir bereits gelesenen Buch zum Thema TDD, Clean Code und Refactoring, werden auch in diesem Buch diese Begrifflichkeiten im ersten Kapitel auf allgemeinster Ebene behandelt.

Testarten

Auch die Fragen wie TDD das Software-Design beeinflusst wird äußerst gut erklärt. Des weiteren findet man Definitionen zu verschiedenen Testarten wie z.B.: Unit-, Integration- und Acceptance-Tests. Allerdings handelt es sich dabei nicht um irgendwelche trockenen, schwer-verstehbaren Beschreibungen, sondern um gut erklärte, leicht nachvollziehbare Sichtweisen auf diese Themen.

Feedback

Die Autoren betonen auch immer wieder wie wichtig Feedback in der Softwareentwicklung heutzutage ist. Man sollte auf jeder Ebene, Mikro- also auch Makroebene, Feedback-Schleifen einbauen, um ständig dazuzulernen und das System wen nötig zu verbessern. Je früher man im Entwicklungsprozess Unklarheiten beseitigt und dadurch Fehler vermeiden kann bzw. aufdeckt desto billiger ist es natürlich auf diese zu reagieren und Verbesserungen vorzunehmen.

Akzeptanztests

Was für mich relativ neu war bzw. was ich nach lesen des ersten Kapitels dazugelernt habe, ist die Wichtigkeit des Akzeptanztests zu verstehen. Bevor man ein neues Feature in einem System hinzufügt, muss der dazugehörige Akzeptanztest geschrieben werden. Inwiefern dieser aussehen muss wird im Buch äußerst gut erklärt. Allerdings bin ich mir noch nicht ganz sicher wie ein solcher tatsächlich im Code festgeschrieben wird. Jedoch beinhaltet das Buch auch einen eigenen Teil wo ein kleines System entwickelt wird. In diesem wird mit Sicherheit auch mindestens ein Akzeptanztest geschrieben.

Qualität in Symbiose mit TDD

Meiner Ansicht nach trägt der Abschnitt über “External and Internal Quality” stark dazu bei, TDD zumindest einmal in einem Projekt ausgetestet zu haben. Es wird ausführlich beschrieben, wie TDD den geschrieben Code qualitätsmäßig in positiver Hinsicht beeinflusst. Wenn man seine Klassen testbar gestaltet, d.h.: man definiert klar die Abhängigkeiten und Verantwortlichkeiten dann erhält man automatisch eine besser Kopplung und Kohäsion seines Designs und ganz wichtig:

“TDD ist eine Technik um mit unvermeidlichen, unvorhersehbaren Veränderungen (in jeglicher Hinsicht) im Softwareentwicklungsprozess umzugehen”.

Also: “Never write new functionality without a failing unit test.”

2 comments:

Anonymous said...

Hallo.
Ich mochte mit Ihrer Website sageniuz.blogspot.com Links tauschen

Anonymous said...

Hallo.
Ich mochte mit Ihrer Website sageniuz.blogspot.com Links tauschen