06. Nov 2013

Andreas Fröwis

6 Min.

Der Joel-Test
12 Schritte zu besserem Code

Die Qualität von Code zu messen, ist schwierig. Es gibt Ansätze, die Metriken wie bei­spiel­sweise Code Coverage ver­wenden, aber auch Ansätze, die die Qualität von Software als "Funktion, die beschreibt, inwiefern die Software die Welt zum Besseren verändert". Das kann auch so interpretiert werden, dass Benutzer­zufriedenheit wichtiger ist als funktionale und strukturelle Qualität.

Und wie misst man die Qualität eines ganzen Software-Teams? Softwareentwicklung ist ein sehr komplexer Prozess und es ist nahezu unmöglich, die Qualität eines Software-Entwicklungsteams genau zu bestimmen. Hier kommt der "Joel Test" ins Spiel!"

Der Joel Test ist eine Erfindung von Joel Spolsky, Co-Founder von Stackexchange und Fog Creek Software. Er beinhaltet die folgenden Fragen:

  1. Do you use source control?
  2. Can you make a build in one step?
  3. Do you make daily builds?
  4. Do you have a bug database?
  5. Do you fix bugs before writing new code?
  6. Do you have an up-to-date schedule?
  7. Do you have a spec?
  8. Do programmers have quiet working conditions?
  9. Do you use the best tools money can buy?
  10. Do you have testers?
  11. Do new candidates write code during their interview?
  12. Do you do hallway usability testing?

Ist doch einfach, oder? Wir haben die Fragen beantwortet und haben uns ein paar Gedanken über ihre Relevanz für die Qualiät eines Software-Entwicklungsteams gemacht.



1. Do you use source control?

Ja. Git in Kombination mit GitHub macht es einfach, sich den Code der anderen Entwicklern anzusehen und darüber zu diskutieren. Dank PHPStorm können wir sogar alle Änderungen, die je in einer Datei gemacht wurden, direkt in unserer IDE überprüfen. Da wir auf verschiedenen Plattformen (Linux, Mac, Windows) in verschiedenen Sprachen (C#, Java, PHP) entwickeln, ist Git für uns sehr gut geeignet, da es auf allen Plattformen funktioniert.

2. Can you make a build in one step?

Ja. Wir können sowohl unsere Community-Lösung "Ribbl" als auch eine Unit-Testing-Umgebung innerhalb weniger Sekunden mit nur einem Script installieren. Zusätzlich haben wir dieses Script in unsere PhpStorm IDE eingebaut, sodass wir nicht mal unsere geliebte Entwicklungsumgebung verlassen müssen.

3. Do you make daily builds?

Ja. Wir haben einen Jenkins CI Server aufgesetzt, der unseren Code nach jedem Git-Commit in drei verschiedenen PHP-Versionen testet. Für alle öffentlichen Projekte (wie beispielsweise Fusonic-Linq) haben wir Travis CI integriert.

4. Do you have a bug database?

Ja. Wir verwenden den GitHub-Bug Tracker für alle öffentlichen Projekte. Abgesehen davon, verwenden wir Mantis - ein recht alter Bug Tracker.

5. Do you fix bugs before writing new code?

Nicht immer. Wir verfolgen Bugs auf unserem Scrum-Board und schätzen den Aufwand für deren Lösung täglich in unserem Daily Scrum. Alle Bugs sind in unserem Bug-Tracker dokumentiert. Dennoch kommt es vor, dass wir neue Features implementieren, obwohl noch einige offene Bugs vorhanden sind.

6. Do you have an up-to-date schedule?

Nicht wirklich. Wir praktizieren Scrum mit Sprints von zwei Wochen. Grundsätzlich basiert Scrum ja auf zeitlich begrenzten Abläufen und Terminen. Am Anfang jedes Sprints planen wir, welche Aufgaben wir in den nächsten zwei Wochen erledigen werden. Unser Scrum-Board wird während unseres Dail-Scrum Meetings täglich aktualisiert. Trotzdem haben wir nicht wirklich eine langfristige Roadmap.

7. Do you have a spec?

Ja. Bevor wir größere Features oder ganze Projekte entwickeln, erstellen wir ein Anforderungsprofil, dass die Spezifikationen und das erwartete Ergebnis beinhaltet. Wenn es bei dem Projekt auch ein komplexeres User-Interface gibt, erstellen wir Mockups und Workflows für das Projekt. Bei Features, die einen Einfluss auf andere Teile eines Projektes haben, erstellen wir Klassen- und API Dokumentationen. All diese Dokumente diskutieren wir gemeinsam in unseren Anforderungsmeetings.

8. Do programmers have quiet working conditions?

Ja. Wir haben sogar beschlossen, keine Meetings mehr vor 15:00 Uhr zu veranstalten. Bei uns ist es nicht unüblich, dass sich manche Entwickler für einige Stunden komplett von ihrer Umwelt mit den magischen Worten "Habidere, i bin im Tunnel!" isolieren, nachdem sie ihre Kopfhörer aufsetzen. :-)

9. Do you use the best tools money can buy?

Ja. Alle unsere Entwickler sind mit Highend-PCs mit SSDs und zwei Monitoren ausgerüstet. Abgesehen davon sind unsere Tische mit einem einfachen Druck auf einen Schalter höhenverstellbar! Das ist besonders für gemeinsame Code-Reviews im Stehen angenehm. In Punkto PHP-Entwicklung setzen wir auf die PhpStorm IDE. In der .NET und C#-Welt verwenden wir Visual Studio auf Windows und Xamarin Studio (Monodevelop) auf Linux und Mac OSX.

10. Do you have testers?

Nein. Zumindest keine "Vollzeittester". Manche von uns betreiben vermehrt Testing-Aufgaben, weil sie diese Art von Arbeit gerne machen. Andere nicht. Dennoch haben wir einige Regeln:

  • Test-Szenarios schreiben
  • Die Person, die den Code testet sollte nicht der Autor des Codes sein
  • Das Hirn einschalten

11. Do new candidates write code during their interview?

Ja. Bewerber absolvieren einen Probearbeitstag. Normalerweise müssen sie an dem Tag eine Programmieraufgabe lösen. Beispielsweise das Entwickeln einer kleinen Webanwendung. Dafür haben die Bewerber einen ganzen Tag Zeit. Am Ende des Tages machen wir eine gemeinsame Code-Review.

12. Do you do hallway usability testing?

Nein. Aber gute Idee!

Wir haben 8 von 12 Punkten erreicht!

Wenn Sie mehr über den Test wissen wollen, lesen Sie einfach Joel Spolsky’s Artikel auf seinem Blog. Auch wenn das ein sehr ungenauer Test ist, sind wir der Meinung, dass diese 12 Fragen eine Menge über die Qualität eines Software-Entwicklungsteams aussagen. Was ist eure Punktezahl? And vor allem, was denkt ihr über den Joel-Test?