Hier einige interessante Statistiken zur coding night . Da die coding night ein „Projekt im Zeitraffer“ war, sind die von Hudson bei den automatischen Builds erstellten Statistiken ganz interessant.
JUnit Test Ausführung
Das erste was auffällt ist, daß es erst ab Build #68 Testergebnisse gab. Der Build fand um 22:28:56 statt, was etwas mehr als 6 Stunden nach dem ersten commit (16:01:27) entspricht. Der Grund ist zum einen, daß erst Verzeichnisstrukturen in den ersten commits aufgesetzt wurden. Zum anderen ist TDD bei nicht vorhandener codebasis auch recht schwer, zumal die ersten Stunde wirklich eher unkoordiniert waren (das erste Scrum of Scrums zur Synchronisation fand um 20 Uhr statt). Allgemein positiv ist der konstante Aufwärtstrend. Die fehlgeschlagenen Tests sind hauptsächlich einem größeren Refactoring geschuldet. Zudem verhinderte zeitgleiches Grillen, daß diese Fehler schnell bemerkt und korrigiert wurden.
Testabdeckung
Der Graph ist auch sehr aufschlussreich, so erkennt man daß die Testabdeckung sehr breit ist, da etwa 90% aller Klassen und Packages abgedeckt wurden. Daß die „Conditionals“ rapide fielen hatte den Grund, daß die Software in der Tat bis Build 83 keine If Verzweigung enthielt. Dies spricht für eine sehr geringe Komplexität, welches der Verwendung von Spring anzurechnen ist, da man selber keine Verzweigungen programmieren muss wenn man immer die richtigen Objekte vom Container übergeben bekommt. Zwar versuchte man dann auch später implementierte Verzweigungen abzudecken, war aber nicht wirklich erfolgreich. Dies liegt meiner Meinung nach daran daß die Verzweigungen durch Fehler/Exception Handling entstehen und nicht so schön testbar sind. Die steigende Methoden und Zeilenabdeckung ist gut, aber insgesamt viel zu niedrig. Die Ursachen dafür sind allerdings nachvollziehbar. So schlagen sich vorbereitete aber nicht genutzte Services (toter code) durch. Auch die Modellklassen und unzählige Getter und Setter sind teilweise nicht extra getestet.
Zusammen zeigen die ersten beiden Statistiken ein positives Bild. Kontinuierliches Testen erfolgt auch in stressigen Projekten und bringt eine gewisse Sicherheit über die Qualität.
Code Wachstum
Abgebildet sind die Zeilen selbstgeschriebenen Codes über Zeit. Man sieht den schnellen Wachstum der Zeilenzahl. Es sieht also nach einem sehr produktivem Projekt auch. Die Verteilung des Codes auf die Entwickler ist interessant, man ist fast geneigt zu sagen: 20% der Entwickler haben 80% des Codes geschrieben. Allerdings relativiert sich dies etwas dadurch, daß die Anwesenheit an dem Wochenende stark schwankte. Die 4-6 stärksten Balken verteilen sich somit auch auf die Entwickler welche fast permanent anwesend waren. Eine Anmerkung am Rande: Letzendlich ist es doch erschreckend, wie viel Code für relativ wenig Funktionalität benötigt wurde. Diesen Kritikpunkt muss Java leider einstecken.
Code Typ
Das Tortendiagramm zeigt es deutlich. Wir haben hauptsächlich Java code geschrieben. JSPs wurden als Views genutzt. XML ist kaum vorhanden, da wir größtenteils Annotations verwendet haben anstelle von langen Spring Konfigurationen. Ausgeblendet aus dieser Ansicht sind Javascriptbibliotheken welche eingebunden wurden aber im src Verzeichnis liegen und damit von FishEye als unser Code gezählt wird. Auch zeigt die Verteilung, daß relativ wenig untestbarers entstanden ist. Ausser den Views, welche in egal welcher Form immer problematisch sind, ist fast der komplette Code mit Java Mitteln testbar.
War dieser Beitrag hilfreich?
Weitere Beiträge
von Fabian Lange
26.3.2015 Dein Job bei codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
Weitere Artikel in diesem Themenbereich
Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog-Autor*in
Fabian Lange
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.