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

Ein Blick zurück in die Geschichte

Ich habe mir schon seit längerem vorgenommen mir ein paar Klassiker durchzulesen. Und natürlich hab ich mir ein nicht ganz alltägliches Buch gleich zuerst rausgesucht: Karl von Clausewitz – Vom Kriege
Natürlich nicht in einer neuen Version, sondern in der Version von Arthur Schurig von 1917.

Es ist schon wirklich erstaunlich dieses Buch zu lesen. Kein Geschichtsunterricht kann das Selbstbild der Berufssoldaten dieser Zeit deutlicher vermitteln als ein Buch das von diesen Soldaten selbst und für ihresgleichen geschrieben wurde. Es wird so offen, direkt und unverblühmt über den Krieg und seine Methoden, von Vernichtung des Gegners vom Menschenbild der Generäle gesprochen wie es heutzutage niemals ein Offizier mehr wagen würde. Heutzutage wird seitens des Militärs (vor allem in Militärstaaten wie z.B: der USA) versucht, die Armee als eine Präzisionsmaschine darzustellen, bei der nur Häuser und Autos von bösen Leuten kaputt gehen und wo man nix zu befürchten hat, denn die eigene Armee ist ja die beste und stärkste und überhaupt. Clausewitz schreibt hingegen von Opfern und Opferbereitschaft, von Gehorsam bis in den Tod um des Sieges willen, er schreibt von den inneren Käpfen der Befehlshaber und wieso sie manchmal sehenden Auges Soldaten in den Tod schicken. Ein Buch das so anders ist als alle die man heutzutage findet. Es klagt nicht an, es verherrlicht nicht (jedenfalls nicht in den Maßstäben seiner Zeit) – es beschreibt.

Da Strategie und Taktik, vor allem im Militärischen, ein recht anregendes Thema ist , habe ich mich dem nicht ganz entziehen können. Strategie und Taktik, in seiner theoretischen Form, ermöglicht es in Spielen/Simulationen sich geistig mit anderen zu messen. Und das ist, vor allem für das männliche Geschlecht, recht anziehend.

Ich habe mir deshalb Zeit genommen und ein Brettspiel entworfen, welches, wie ich finde, recht gut gelungen ist. Es nennt sich: Der Taktikkasten.
Die Regeln sind so gehalten, dass man ohne Zufallselement (Würfel) auskommen soll. Falls die Regeln sich behaupten, kann das Spiel genau wie Schach über analoge Medien wie z.B. Briefen, Zeitungen oder über Chat und EMail gespielt werden.

Hier einmal ein Bild vom Kasten zum anfüttern 😉 :

Alle Bestandteile des Taktikkasten ausgebreitet. (Klick für größere Version)

Mittlerweile habe ich noch mehr Leute im Internet gefunden die Taktik/Strategie-Spiele basteln. Unter anderem auch eine Gruppe, welche diese Spiele im Geschichtsunterricht einsetzen um zu erklären, was in den Schlachten passiert ist und wie eine Schlacht damals abgelaufen ist.

Nebenbei: Die Idee eines solchen Spiels ist keine neue. Das orginale „Kriegsspiel“ wurde im Preußen des 19.Jh entwickelt und war dort bei den Offizieren sehr populär. Und somit schließt sich der Kreis zu Karl von Clausewitz. Dieser kämpfte ja u.A. gegen Napoleon Anfang des 19.Jh. und wurde später als einer der besten Napoleon-Versteher, man könnte fast Schüler sagen, angesehen.