XML...

http://c2.com/~ward/ascent.jpg

(Danke an Sebastian für den Link)

Post bewerten

W-JAX 2007

Nicht nur die XP-Days stehen vor der Tür, sondern auch die W-JAX. Meine Firma ist wieder mit Stand eine Vorträgen vertreten.

Gleich am Anfang des Agile Day halte ich zusammen mit meinem Kollegen Henning Wolf einen Vortrag über Festpreisverträge in agilen Projekten. Dieses Thema treibt uns ständig um. Auf der einen Seite ist klar, dass klassische Festpreiskonstellationen schlecht zu agilen Vorgehensweisen passen, weil sie unter anderem das Lernen "verbieten". Allerdings sind die Alternativen rar. Stattdessen Aufwandsprojekte vorzuschlagen, ist zu sehr aus der Perspektive der Entwickler argumentiert. Aber der Wurm muss dem Fisch schmecken und nicht dem Angler. Und das tut er bei Aufwandsprojekten in der Regel nicht. Denn der Auftraggeber verliert ein gutes Stück der Kontrolle über die Kosten-Nutzen-Relation seines Projektes. In dem Vortrag wird es also sehr stark um das gehen, was sich zwischen Festpreis und Aufwand abspielen kann.

Ich organisiere außerdem die Lightning Talks auf dem Agile Day. Im Gegensatz zu den Lightning Talks auf den XP-Days stehen auf der W-JAX die reinen Anfängerthemen nicht im Vordergrund.

Und wie bei den XP-Days gibt es es auch bei der W-JAX ein Speaker-Logo:

Post bewerten

XP-Days 2007

Die XP-Days 2007 stehen vor der Tür und zwar am 22. und 23. November in Karlsruhe. Das Programm bietet ein breites Themenspektrum.

Für Einsteiger in die agile Softwareentwicklung liefern die Lightning Talks am 22.11.07 einen guten Überblick. Neben den Inhalten ist die Präsentationsstruktur sehr interessant: viele kurze Vorträge, die jeweils eine Aussage genau auf den Punkt bringen.

Am 23.11.07 werde ich dann etwas zu einem meiner Lieblingsthemen sagen: Einfachheit in Softwareprojekten.

Aber eigentlich schreibe ich diesen Blog-Eintrag nur, damit ich Gelegenheit habe, das coole XP-Days-Speaker-Logo zu verwenden, das mein Kollege Bernd Schiffer erstellt hat.

Post bewerten

Klassen und Methoden im Wandel

Als ich studierte gab es genau eine Art, Klassen und Methoden zu benennen: Klassen wurden mit Substantiven benannt, die direkt dem ungesetzten Konzept bzw. ihrer Verantwortlichleit entsprechen sollten, z.B. Auftrag. Bei den Methoden wurde streng zwischen Funktionen und Prozeduren unterschieden. Funktionen liefern Werte und lassen den Objektzustand schön in Ruhe, während Prozeduren den Objektzustand ändern und keinen Rückgabewert haben. Ob etwas Funktion oder Prozedur ist, sollte nicht nur an der Signatur deutlich werden, sondern auch im Namen. Prozeduren werden immer in Befehlsform geschrieben (z.B. berechneSumme) während Funktionen eine Substantivform bekommen (ggf. mit einem 'get' als Präfix, z.B. 'getNummer'). Diese ganze Konzeption wurde z.B. von Bertrand Meyer vertreten und auch gut begründet:
Wenn man eine Klasse sucht, kann man sie leicht anhand ihres Namens finden. Und wenn man dann das API der Klasse liest, ist gleich klar, was die Methoden tun. Insbesondere ist klar, ob eine Methode nur einen Wert liefert oder ob sie gefährlich den Objektzustand manipuliert.

In den letzten Jahren hat sich an verschiedenen Stellen ein deutlich anderer Programmierstil entwickelt. Der primäre Fokus hat sich gewandelt. Es geht nicht mehr primär darum, dass man das API einer Klasse leicht lesen und verstehen kann. Stattdessen soll der Klientencode möglichst gut lesbar sein.

Bei der Benennung von Unit-Tests findet sich eine zarte Andeutung in diese Richtung. Statt AuftragTest.testSummenberechnung findet man heute immer häufiger AuftragTest.berechnetSummeDerPositionen. Die zweite Variante lässt sich als Spezifikation lesen "Auftrag berechnet Summe der Positionen".

Noch deutlicher wird es, wenn man sich Behaviour Driven Development (BDD) ansieht.

Schließlich nutzen die Fluent Interfaces dieses Konzept auch außerhalb des Testens bzw. Spezifizierens für Produktivcode.

Aus

TimeInterval meetingTime = new TimeInterval(fiveOClock, sixOClock);

wird

TimeInterval meetingTime = fiveOClock.until(sixOClock);

Für viele Entwickler, die schon länger im Java- oder C++-Geschäft sind, sind diese fließenden Interfaces sehr gewöhnungsbedürftig. Allerdings wird eine Klasse viel häufiger eingesetzt als gelesen. Also scheint es nicht gerade abwegig, mehr Gewicht auf die Benutzbarkeit als die API-lesbarkeit zu legen.

Trotzdem wird man absehbar wohl nicht alle Klassen mit einem Fluent Interfaces versehen. Dazu ist der Aufwand zu groß. Aber bei den Klassen, die sehr häufig benutzt werden, sind Fluent Interfaces sicher eine Überlegung Wert.

Nachtrag: Ein Beispiel für ein Fluent Interface findet sich z.B. in Hibernate, wenn man eine Criteria zusammenbaut.

Post bewerten