Zum Teamevent im Entwicklungsteam haben wir uns dieses Mal vorgenommen ein Coding Dojo durchzuführen.

 

Was ist denn ein Coding Dojo?

Das Coding Dojo lehnt sich an das japanische Dojo an. Dort ist ein Trainingsraum für Kampfkünste in dem man sich Praktiken aneignen und die eigenen Fähigkeiten verbessern kann. Und genauso ist es auch im Coding Dojo wenn Softwareentwickler sich gemeinsam einem Problem widmen.

 

Was ist denn das Ziel dabei?

In der Softwareentwicklung entwerfen wir oft neue Architekturen, bringen verschiedene Systeme und Komponenten zusammen und müssen uns ständig an den neusten Technologien messen. Dabei darf der Entwickler aber das Handwerkszeug nicht vernachlässigen. Beim Coding Dojo werden einfache Probleme bearbeitet um Standardentwicklungsabläufe (das Handwerkszeug) zu trainieren. Da dies gemeinsam getan wird erfolgt hierdurch ein reger Austausch über die Art des Entwickelns. Durch dieses Training und den gemeinsamen Austausch erhöhen sich die Qualität des Codes und das Bewusstsein für Qualität immens.

 

Und was macht man dann genau?

Zunächst benötigt man einen Konferenzraum mit Beamer und einen Laptop mit Entwicklungsumgebung. Am Rechner sitzen immer ein Pilot und ein Co-Pilot. Der Rest des Teams schaut zu und kann Anmerkungen zum Code geben.

Für die Entwicklung sucht man sich dann eine Herausforderung, die Kata genannt wird, aus. Dies ist eine abgeschlossene Programmieraufgabe z.B. kann man die FizzBuzz-Kata benutzen (http://codedojos.wordpress.com/kata-ubersicht/kata-fizzbuzz/).

Der Co-Pilot sagt dem Piloten was dieser im nächsten Schritt programmieren soll. Nachdem dieser den Schritt abgeschlossen hat und der Code oder Test funktioniert wechselt der Co-Pilot zurück ins Publikum, der Pilot auf den Platz des Co-Piloten und jemand aus dem Publikum auf den Platz des Piloten.

 

Tests? Was hat es denn damit auf sich?

Eine Sache die ich bisher nicht erwähnt habe ist, dass für ein Coding Dojo testgetriebene Entwicklung (Test Driven Development = TDD), eine andere Art der Entwicklung verwendet wird, die aber aufgrund Ihrer Qualitätsbewussten Arbeitsweise auch in ganz normalen Projekten Verwendung finden kann.

Bei testgetriebener Entwicklung schreibt der Entwickler einen sogenannten Unit-Test bevor er den eigentlichen Code entwickelt. Der Unit Test beschreibt die fachliche Anforderung wie das Programm funktionieren soll und wird ebenso in Code ausgedrückt.

Nachdem der Entwickler den Test fertiggestellt hat, schreibt er den eigentlichen Code dazu. Und zwar nur so viel bis sein Test funktioniert. Damit sollen große und umständliche Funktionen vermieden werden.

Der größte Vorteil von TDD ist, dass der entwickelte Code automatisch wartbarer und lesbarer wird. Zudem kann man bei Änderungen oder Fehlerbehebung alle Tests laufen lassen und schauen ob man nicht aus Versehen an einer anderen Stelle einen Fehler eingebaut hat.

 

Und was bringt dies der HanseVision?

Wie schon in den Zielen erwähnt erhöht sich sowohl das Qualitätsbewusstsein als auch die Qualität des Codes. Durch die Nutzung von testgetriebener Entwicklung haben wir bei mittleren und größeren Projekten immer ein Sicherheitsnetz aus Tests besitzen, die es ermöglichen schnell Änderungen an den Anforderungen durchzuführen oder Fehler ohne Nebenwirkungen zu entfernen.

Zu guter Letzt hat uns das Coding Dojo im Entwicklungsteam jede Menge Spaß gemacht und wird auch nicht das letzte gewesen sein.

Und vielleicht können wir ja auch einmal ein Coding Dojo mit Ihnen durchführen?

1 Comments

  1. Pingback: Erstes Coding Dojo bei der HanseVision - SharePoint Blogs in German - Bamboo Nation

Leave a comment

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Time limit is exhausted. Please reload the CAPTCHA.