Vortrag zu Responsive Design by Kent Beck

Ich schaue gerade Kent Becks Vortrag zu Responsive Design an und versuche hier mal meine Gedanken zu den Thema nieder zu schreiben. Hier der Link:

http://www.infoq.com/presentations/responsive-design

Die Seite sieht etwas unübersichtlich aus. Nicht sofort zu erkennen war, dass das Video links nicht alles ist, sondern rechts daneben die Vortragsfolien parallel zum Video umschalten. Also nicht einfach (wie gewohnt) das Video in den Vollbildmodus schalten.

Retrospektive mit Karteikarten

Das sollte man auf Arbeit mal unseren Vordenkern vorschlagen. Hier wendete Kent das „Continuos Improvement“ Pattern auf sich selbst an. Wer macht das eigentlich sonst noch. Häufig wird herzlich gestritten, eine Lösung gefunden und schnell wieder an die Arbeit gegangen. Aber zu dokumentieren warum gestritten/um eine Lösung gerungen wurde und wie und warum das Ergebnis ist wie es ist, das passiert sehr selten. Wahrscheinlich einer der Gründe wieso Kent Beck ein so gefragter Entwickler ist. Er macht nicht nur, sondern er denkt auch darüber nach wieso er es so macht.

Designprinzipien

Kent erwähnt Designprinzipien als Leitfaden für die Entwicklung eines Softwaresystems. Ich kann das nur bestätigen und merke leider immer wieder, dass genau diese bei der Arbeit zwar allen bekannt sind, jedoch häufig nicht dokumentiert werden. Wenn dann Jahre später die ursprünglichen Programmierer weg sind und andere an dem System arbeiten (und andere Prinzipien anwenden) entsteht schnell schlecht wartbarer Code, da Entscheidungen nicht konsistent weiter geführt werden.

Problemlösungs- / Refactoringstrategien

Leap – Sprung

So wie ich Kent verstehe ist der Leap der gefährlichste, jedoch auch schnellste Weg eine Änderung zu erreichen. Solange ich glaube(!) es schaffen zu können sollte ich den Leap versuchen. Sobald ich aber (unterwegs) unsicher werde und das System nicht mehr läuft, gehe ich zurück zum Startpunkt und versuche eine alternative Methode. Kent bringt als Beispiel eine Anwendung wo er sein Designprinzip „Streams statt Filenames“ verletzt hatte. Er wollte nun die Filenames durch Streams ersetzen. Da er 4-5 Klassen anpassen musste ging er davon aus, dass er das so hinbekommt, und wagte den Sprung (Leap). Als er merkte, dass es zu undurchsichtig wurde, änderte er alles wieder zurück und versuchte einen anderen Ansatz.
Interessant war, dass Kent Beck, Author von JUnit, hier zugegeben hat, dass auch bei ihm hin und wieder keine gute Testabdeckung vorkommt. Um überhaupt zu wissen, ob ein Leap erfolgreich war, braucht man Testabdeckung. „Refactoring nur unter Testcoverage“ sollte jedem als Prinzip bekannt sein.

Parallel – Redundanz

Bei Parallel wird ein „zweiter Weg“ ein Problem zu lösen neben den aktuellen (nicht mehr gewollten) gestellt.
Kent bringt wieder das Beispiel „Ersetzen von Filenames durch Streams“. Hier kann man sich vorstellen, dass solch eine Änderung an diversen Stellen in einem SW System schnell unübersichtlich wird.
Kent sagt nun, dass die Parallel-Entwicklung ein sichererer Weg ist. Das kann man so hinnehmen, ich frage mich aber „An welchem Ende des Systems sollte man mit der Umstellung auf Streams beginnen“?

Ich glaube das man vom Ende her beginnen sollte. Also dort wo aktuell die Filenames aufgelöst und die Inhalte gelesen werden, schreibt man eine zweite Methode, welche einen Stream benutzt und zieht die Business-Logik dahin um. Man weiß, dass die Logik funktioniert. Einzig neuer Punkt ist nun, dass Streams statt File-Operationen genutzt werden. Tritt ein Fehler auf weiß man genau, wo man suchen muss. Alle anderen Klassen arbeiten weiter mit Filenames und rufen auch an meiner Klasse die alte Methode mit Filename auf. Die Alte Methode ist aktuell quasi leer. Statt dessen schreibe ich nun dort den Code zum umwandeln eines Filenames in einen Stream hinein und rufe meine neue Methode. Nachdem das alles funktioniert gehe ich zur der Klasse welche meine alte Methode aufruft und schreibe dort eine alternative Methode mit Streams. Diese kann jedoch sofort die neue Methode nutzen. Damit ist die alte Methode an der ersten Klasse nun nutzlos geworden und kann entfernt werden. So gehe ich schritt für Schritt voran und stelle den Code um.

Stepping Stones – Zwischenschritte

Wirklich klar wird das Prinzip durch die Phrase „Wenn ich XYZ hätte, wäre das nicht so schwer“. In so einem Fall baut man sich ein XYZ und macht dann weiter. Notfalls stellt man das XYZ erstmal neben (Parallel) den restlichen Code.
Stepping Stones können leicht overdesigned werden. Also KISS anwenden.

Simplification

Kernidee hier ist: Auf welche primitive Form kann ich das Problem eindampfen? Wenn ich z.B. die Aufgabe habe einen Differentialgleichungs-Löser zu schreiben, der mit bis zu 20 unbekannten arbeiten kann, dann wäre es eine gute Idee mit einem zu beginnen wo keine unbekannte enthalten ist. Und dann einen mit einer Unbekannten. Und dann einen mit zwei. Und dann fällt dabei fast schon von alleine der mit n Unbekannten hinten ab.

Successions – Abfolgen

Die restlichen Folien werden sehr schnell abgehandelt. Von Interesse fand ich die Idee der Successions. Kent vermutet, dass es bei der Arbeit immer wieder Schritte gibt die man nach und nach durchführt um erfolgreich zu sein. Eine dieser Abfolgen ist das bei Simplification erwähnte Prinzip erst „Eine Lösung für 1 Element herzustellen und dieses dann auf mehrere Elemente zu erweitern“ (First One – Than Many). Kent vermutet, dass es noch weitere solcher allgemeinen Abfolgen gibt.

Schlussfolgerung

Ein Vortrag den man sich durchaus mal anschauen sollte.

Werbung