 |
|
|
|
Diktatoren, Twitteraccounts und SOLIDes Design (Bernd Schiffer, Marko Schulz)Auf den XP Days 2008 wurde ein außergewöhnliches Experiment gestartet: Von Johannes Link initiiert, gründeten sieben Teilnehmer das PPfgB, das Programmier-Projekt für gelangweilte Berater. Des alleinigen, agilen Beratens überdrüssig, galt es in diesem Projekt wieder das Schwert der Programmierkunst neu zu schärfen. Berater und Programmieren? Kann das gut gehen? Berater reden gerne. Und jeder kennt die bessere Lösung. Naheliegend kam es so auch zu mancher Kontroverse um Designentscheidungen. Zu welchem Design treiben einen die Tests wirklich? (Ver)Leiten einen die SOLID-Prinzipien zu nicht-agilen Vorgehensweisen, stehen also beispielsweise gegen YAGNI oder KISS? Zugespitzt: Ist die nachfolgende Klasse nach SOLID gutes Design oder nicht - und warum? Und passt das mit agilen Vorgehensweisen wie TDD und DRY zusammen?
class Diktator {
def twitteraccount
}
SOLID kürzt ganz enorm das Single Responsibility Principle, das Open-Close-Principle, das Liskov
Substitution Principle, das Interface Segregation Principle und das Dependency Inversion Principle ab.
Diese Technik ist in der Agilen Softwareentwicklung hoch angesehen: SOLID ist seit mehr als einem
Jahrzehnt das scharfe Skalpell, mit dem der Host des Agilen Manifests Robert C. "Uncle Bob" Martin
gutes von schlechtem Design trennt.
TDD (Test-Driven Design), DRY (Don't Repeat Yourself), YAGNI (You aren't gonna need it!) und KISS (Keep it simple, stupid!) sind etablierte agile Verfahren innerhalb von Extreme Programming, Scrum und den Pragmatic Programmern. Aber was nützt SOLID, wenn es so schwer in der Praxis mit Agilen Verfahren und Prinzipien anwendbar ist? Wie weit will man SOLID verfolgen? Bis ins extreme? Oder nur soweit, wie es pragmatisch ist? Aber wird SOLID dann nicht wieder nur zu Wischiwaschi-Regeln, die jeder so auslegt, wie es ihm gerade passt? Wann fängt man an mit SOLID und wann hört man auf? In dieser Session wollen wir an obigem Beispiel praktisch zeigen, wie konstruktiv Diskussionen in der Agilen Softwareentwicklung sein können. Wann die Grenze zu YAGNI und Design auf Vorrat erreicht wird. Wann Verfahren und Prinzipien helfen und wann sie im Weg sind. Wann der "Last Responsible Moment for Decision" bzgl. des Designs ist. Die Session richtet sich an erfahrene Entwickler, denen diese Verfahren und Prinzipien im Grunde nicht neu sind, denen diese Verfahren und Prinzipien aber immer mal wieder ein Bein stellen. Über die Referenten
E-Mail: bernd.schiffer@it-agile.de Twitter: berndschiffer
E-Mail: Marko.Schulz@it-agile.de Twitter: datenreisender |
Dipl.-Inf. Bernd Schiffer ist Agiler Berater bei der it-agile GmbH in Hamburg.
Er hat mehrjährige Erfahrung aus agilen Softwareprojekten (vor allem: eXtreme Programming, Scrum) als
Entwickler, Projektleiter, Coach und Trainer, sowie als Sprecher auf Konferenzen. Darüber hinaus
interessiert er sich für TDD, Groovy, Grails, DSLs und guten Code. Er studierte Informatik an der Universität Bremen.
Marko Schulz ist Softwareentwickler. Seit vielen Jahren praktiziert und fördert
er agile Vorgehensweise in Softwareprojekten, mit einem besonderem Augenmerk auf dem Gleichklang zwischen
guter Programmierung, Architekturentwicklung und Prozessverbesserung. Er arbeitet für die it-agile GmbH.