Wann standst Du zum letzten Mal vor einem grossen Berg an Programmcode und hast versucht ihn zu verstehen? Wie bist Du da vorgegangen? Durch wie viele Klassen Java- oder .NET-Code hast Du dich gewühlt? Hast Du alle Referenzen auf den schlechten Code gefunden? Bist Du sicher, dass Du sie alle gefunden hast? Und wie lange hast Du dafür gebraucht? Oder ist der Debugger dein bester Freund?

Obwohl die Entwicklingsumgebungen in den letzten Jahren immer mächtiger geworden sind, hat es bisher nur für eine relativ bescheidene Navigation durch den „Abstract Syntax Tree“ (AST) gereicht, und sonst behilft man sich mit einfachen grep- und regex-Suchen.

Doch die Menge an Code und die Fülle an Medienbrüchen nimmt stetig zu, und es wird immer schwieriger sich einen guten Überblick über die Codebasis zu verschaffen, um informierte und fundierte Entscheidungen bezüglich Design und Problembeseitigung zu treffen.

Selbst testgetrieben entwickelter Code, der aktuell mit zum Besten gehört, dass wir Softwerker produzieren, wird mit zunehmendem Umfang tendenziell unerbittlich komplexer und schwieriger in seiner Gesamtheit versteh- und manipulierbar. Besonders wenn mehrere Leute an einer gemeinsamen Codebasis arbeiten, die über mehrere Generationen von Mitarbeitern gepflegt werden muss, stehen sie vor ebensolchen Herausforderungen.

Da wurde es Zeit, dass sich jemand um die manchmal verloren geglaubte Kunst der Code-Analyse, d.h. die systematische Musterung von Code, ernsthaft bemüht. Dieser Schritt ist nun mit der Lancierung des „humane assessment“ getauften Ansatzes getan.

the humane assessment method
the humane assessment method

Tudor Girba hat es nicht dabei belassen, ein als Open Source publiziertes Tool zur mächtigen Code-Analyse in die Welt zu setzen, sondern sich darüber hinaus überzeugend Gedanken gemacht, wie ein solches „Assessment“, die Beurteilung von Code, in agile Entwicklungsverfahren, ergänzend eingebracht und verankert werden kann.

Seine Argumentation zugunsten eines kontinuierlichen Code-Assessments stützt er dabei auf viele Erfahrungen, die er und andere „Mooser“, in unterschiedlichsten Projektkontexten gemacht haben. Dabei stechen dem geneigten Entwickler zwei fundamentale nutzbringende Anwendungen ins Auge:

  • Die Möglichkeit grosse Mengen an Code gezielt zu filtern und auf dem reduzierten Set an selektierten Stellen im Code, selbst komplexe Analysen und gar Transformationen durchzuführen. Durch die Freiheit eigene Parser, Filter, Transformatoren und Visualisierungen zu implementieren, sind den Möglichkeiten fast keine Grenzen gesetzt.
  • Eine weitere interessante Option besteht in der Möglichkeit wiederkehrend, z.B. im Build-Prozess, die Einhaltung von Architektur- und Design-Regeln automatisiert zu überprüfen, und so eine Bastion gegen die stete Entropie von gutem Code zu errichten.

Mehr über „humane assessment“ erfährst Du auf der einschlägigen Website.

Scrum, als agile Vorgehensweise, kennt einen eingebauten kontinuierlichen Verbesserungsprozess. Dies ist einer der elementaren Vorteile des Rahmenwerks, vorausgesetzt natürlich, man führt Retrospektiven tatsächlich durch und handelt anschliessend aufgrund der dort aufgebrachten Probleme.

thinkingoutofbox

Ein nützliches Werkzeug Retrospektiven inhaltsvoller und auch zielgerichteter zu gestalten, stellen die in Rolf Smith’s Buch „The 7 Levels of Change: Different Thinking for Different Results“ (3rd Edition, Tapestry Press 2007) beschriebenen Ebenen des Nachdenkens dar. Sie helfen Probleme aus verschiedenen Blickwinkeln zu betrachten. Dadurch kann man mehr alternative Ansätze zur Lösung eines Problems generieren.

Die 7 Ebenden des Nachdenkens sind: Effektivität, Effizienz, Verbesserung, Reduktion, Nachahmung, Originalität und Unmögliches.

Wir wollen uns im Folgenden einen Überblick schaffen, wie wir sie in der Praxis verwenden können. Wir können die 7 Ebenen wie Kategorien von Fragen betrachten, die wir uns im Team stellen und beantworten sollten.

Ebene 1: Effektivität

Ziel: Die richtigen Dinge tun

Fragen, die wir uns stellen können:

  • Was hat Priorität?
  • Was ist dem Kunden wichtig?

Ebene 2: Effizienz

Ziel: Die Dinge richtig tun

Fragen, die wir uns stellen können:

  • Wie schreiben wir gute Tests?
  • Wie können wir eine gemeinsame Sprache mit dem Kunden finden?

Ebene 3: Verbesserung

Ziel: Die Dinge besser tun

Fragen, die wir uns stellen können:

  • Wie optimieren wir die Laufzeit unserer Tests?
  • Wie können wir die Kommunikation zum Kunden verbessern?

Ebene 4: Reduktion

Ziel: Dinge nicht mehr tun

Fragen, die wir uns stellen können:

  • Auf welche Dokumente können wir gefahrlos verzichten?
  • Welche Features können weggelassen werden?

Ebene 5: Nachahmung

Ziel: Dinge tun, die andere tun

Fragen, die wir uns stellen können:

  • Können wir den Testansatz des anderen Teams übernehmen?
  • Wie können wir dieses bewährte Design Pattern bei unserem Problem anwenden?

Ebene 6: Originalität

Ziel: Dinge tun, die sonst niemand tut

Fragen, die wir uns stellen können:

  • Können wir Behavior-Driven Design ausprobieren?
  • Können wir unser Projekt-Portfolio mit Kanban verwalten?

Ebene 7: Unmögliches

Ziel: Dinge tun, die unmöglich scheinen

Fragen, die wir uns stellen können:

  • Kann der Direktor der Behörde, die unser Kunde ist, unser agile Vorgehensweise für uns verkaufen?
  • Wie schaffen wir es, ein grosses Softwaresystem 26-mal im Jahr an 10 Kunden gleichzeitig in Produktion auszuliefern, ohne dass sie je einen Betriebsausfall haben?
  • Wie überzeugt man nichtagile Unternehmen zusammen mit uns agil vorzugehen?

Auf Seite 138ff meines Buches „Agile Prozesse: Fallstricke erkennen und vermeiden“ gehe ich mehr ins Detail, wie
dieses Tool in der Praxis angewendet werden kann.