Der Joel Test - 12 Stufen zu besserem Code

Joel Spolsky ist Softwareentwickler und hat unter anderem Stack Overflow gegründet. Ohne Stack Overflow wüsste heute vermutlich keiner mehr, wie man programmiert. Jetzt bin ich durch Zufall auf einen Artikel von Joel Spolsky gestossen. Es gibt bereits sehr viele gute Übersetzungen zu dem Artikel, dennoch mache ich mir die Mühe und schreibe auch noch etwas dazu, denn es kann einfach nicht oft genug erwähnt werden, wie man besseren Code schreibt. Es handelt sich hier nicht um eine Übersetzung, sondern um meine Sicht der Dinge auf dieses wunderbare Dokument. Den Link zu Joel's Originaltext hinterlege ich ganz unten.

Laut Spolsky sollte ein Unternehmen mindestens 10 der 12 Fragen sofort mit JA beantworten können. Alles unter 10 Fragen deutet auf eine kommende Katastrophe hin.

  1. Existiert eine Form von Versionskontrollsystemen?
  2. Ist es möglich, eine auslieferbare Version der Software in einem Schritt herzustellen?
  3. Wird Continuous Integration benutzt?
  4. Gibt es eine Bug-Datenbank?
  5. Werden Fehler gefixt, bevor neue Features geschrieben werden?
  6. Gibt es einen immer aktuell gehaltenen Plan?
  7. Gibt es Spezifikationen?
  8. Haben die Programmierer eine ruhige Arbeitsumgebung?
  9. Werden die besten existierenden Werkzeuge benutzt, die man kriegen kann?
  10. Werden Unit-Tests geschrieben?
  11. Demonstrieren Job-Bewerber ihr Programmier-Können in einer nachvollziehbaren Art und Weise während des Bewerbungsgesprächs?
  12. Gibt es den Flur-Test?

Existiert eine Form von Versionskontrollsystemen?

Versionskontrollsysteme sind Programme, die alle Änderungen in einem Dokument/Quelltext protokollieren und dir zu jeder Zeit erlauben, zu einem früheren Stand des Codes zurück zu springen. Es sind möglich, Teilbereiche des Codes „auszulagern“ und anschließend diesen Entwicklungszweig wieder in den Hauptcode zu übernehmen. Das erlaubt im Team eine wesentlich modularere Arbeit und beschleunigt den Fertigungsprozess. Aber auch als Einzelkämpfer ist es fahrlässig, kein Versionsmanagement zu nutzen. Früher hat man so einen Mist hier erstellt: meinCode.php.old, meincode.php.oldversion, meinCode.php.backup. Anschließend wusste keiner mehr, welche der Old-Dateien denn nun diejenige ist, die tatsächlich und wirklich funktioniert hat.

Natürlich können mit einer Versionskontrollsoftware auch mehrere Leute an ein und demselben Code arbeiten, ohne die Änderungen des jeweils anderem Teammitglied zu überschreiben. Beim Zusammenführen des Codes („merge“) hat man ein zusätzliches Qualitätsmerkmal, weil bei händischen Änderungen noch einmal eine Sichtprüfung durchgeführt wird. Die aktuell besten Systeme sind SVN, Mercurial oder auch git.

Ist es möglich, eine auslieferbare Version der Software in einem Schritt herzustellen?

Je mehr Schritte notwendig sind, um eine lauffähige Version der Software direkt liefern zu können, desto größer ist die Anfälligkeit für Fehler. Bei Webseiten bedeutet das: Sind alle notwendigen Stylesheets da? Alle Grafiken? Laufen alle Javascripts? Sind alle Dateien so gut wie möglich komprimiert, um einen schnellen Datentransfer zu ermöglichen? Sind eventuell Änderungen an der Datenbank gemacht worden und müssen Felder neu definiert oder erstellt werden?

Wenn man händisch die CSS-Daten zusammenpacken muss (Bootstrap.css+eigene Anpassungen + Jquery + eigener Code), vergisst man garantiert irgendwas. Daher sollte man sich ein Skript erstellen, welches diese lästigen Aufgaben übernimmt. Man sollte auch ein Skript haben, das die Datenbanken nach eventuellen Problemen/Anpassungen durchsucht und anschließend den Code deployen. Man sollte natürlich IMMER eine Möglichkeit haben, die vorherige Version wieder herzustellen. Die „Build“-Version sollte anschließend nochmal durch die Qualitätssicherung gehen und nach Freigabe dann auf das Live-System ausgeliefert werden.

Wird Continuous Integration benutzt?

Continuous Integration, also „Kontinuierliche Integration“, bezeichnet ganz vereinfacht gesagt, dass man den Code jederzeit prüft und immer sofort sehen kann, ob das fertige Produkt läuft oder nicht. Es werden automatisierte Unittests durchgeführt und es gibt ständig einen lauffähigen Stand für Test- oder auch Vertriebszwecke. Für Entwickler bedeutet das, dass man eigentlich immer lauffähige Bibliotheken einchecken will, da sonst der Nightly-Build gar nicht erst funktioniert. Das bedeutet auch, dass man keine unfertigen Codes mehr in das gemeinsame Hauptrepository pumpt. Insgesamt soll CI dadurch die Qualität der Software verbessern. Bekannte Systeme sind Bamboo, Jenkins, Travis CI oder PHPCI.

Gibt es eine Bug-Datenbank?

Coder neigen dazu, sich Bugs immer nur merken zu wollen. „Ich weiß, dass man hier nicht mehr als 99 eingeben kann, das macht aber eh keiner!“ kann man sich exakt so lange merken, bis tatsächlich ein Bug auftaucht, der massive Probleme verursacht oder aber sogar dafür sorgt, dass der Endkunde wirtschaftliche Schäden erdulden muss. Wenn in einem Onlineshop auf einmal jedes Produkt nur noch einen Euro kostet, spricht sich das innerhalb von sozialen Netzwerken innerhalb von Sekunden herum.

Bugs müssen notiert werden. Jeder! Einzelne! Bug! muss aufgezeichnet werden und so protokolliert sein, dass jeder andere Entwickler diesen Bug reproduzieren kann. Das eliminiert auch das andere Statement jedes Coders „bei mir hat das aber funktioniert!“

Davon abgesehen, sollen sich Entwickler Projektdaten merken und den Kopf frei haben von Bugfixes. Kein Mensch kann sich das alles merken.

Werden Fehler gefixt, bevor neue Features geschrieben werden?

Wenn Du weißt, dass dein Programm ein Problem hat, dann beheben dieses Problem, bevor du dich an ein neues Feature machst. Wenn Du zum Beispiel weißt, dass eine Funktion auf jedenfall einen Wert zurück geben muss, diese Funktion das aber nur tut, wenn andere Funktionen keine Fehler machen, schreibe nicht hin, return something(), denn du hast dann zwar ein lauffähiges Programm, aber jeder andere Coder wird NIEMALS darauf kommen, dass du scheisse gebaut hast.

Bei simplen Tippfehlern sagt dir deine IDE normalerweise, dass etwas nicht stimmt. Das behebst du doch auch sofort. Schreibe kein neues Feature, bevor du nicht alle bekannten Fehler behoben hast. Du wirst diese Fehler vergessen oder diese Fehler ziehen Folgefehler nach sich und irgendwann ist dein Projekt so aufgeblasen, dass die Fehlersuche ein unfassbar langwieriger Prozess wird.

Gibt es einen immer aktuell gehaltenen Plan?

Software schreibt man, weil sie etwas tun soll. Die Idee hinter einem Programm ist es immer, dass eine Aufgabe erfüllt werden soll. Damit man niemals vergisst, was das Programm eigentlich machen soll, erstellt man sich einen Plan. Dieser Plan ist die Straßenkarte. Anhand dieses Planes wird festgelegt, welche Features als nächstes eingebaut werden. Wenn Feature A und B noch nicht funktionieren, fängt man auf keinen Fall mit Feature C an. Der Plan darf flexibel sein, muss aber für jedes Mitglied des Teams sichtbar sein und im Zweifelsfall auch mit dem Team reorganisiert werden.

Gibt es Spezifikationen?

Spezifikationen legen fest, was das Projekt tun soll. Specs legen auch fest, wie das Projekt auszusehen hat. Damit sind keine Romane gemeint. Eine Bleistiftskizze kann ein Webseitenlayout genau so gut beschreiben, sogar besser, als wenn irgendwer direkt loslegt und irgendwas in HTML/CSS zusammen frickelt. Das ist eh das Hauptproblem bei Codern. Du sagst dem Programmierer, dass er „Hallo Welt“ auf dem Bildschirm ausgeben soll und er schreibt sofort 10 Zeilen Code. Programmierer sind teuer. Die Arbeitszeit ist teuer. Der Programmierer kann auch genau so gut eine einzige Zeile auf nem Zettel schreiben: „Ich gebe Hallo Welt aus!“

Bevor dann losgestiefelt wird, sollte man immer sagen: Keine Zeile Code ohne die entsprechende Spezifikation. So vermeidet man irre Entwicklungen in verschiedene Richtungen. Und ja, das geht schon bei so einfachen Dingen wie Schriftarten los. Wenn der eine Coder die Seite mit Verdana ausgibt, der andere aber Times New Roman verwendet, hat man ein Designproblem, das man erst mühevoll beseitigen muss.

Haben die Programmierer eine ruhige Arbeitsumgebung?

Programmieren ist Kopfarbeit. Schwerste Kopfarbeit. Das Hirn eines Programmierers muss sich warm machen. Das Hirn funktioniert bei einem Programmierer so ähnlich wie der Muskel eines Bauarbeiters. Ohne ein Aufwärmen funktioniert es nicht. Wenn das Gehirn dann im Tunnel eingetaucht ist, im sogenannten Flow (Fluss) ist, kann der Programmierer konzentriert loslegen und arbeiten. Sobald irgendwas den Programmierer aus seinem Konzept reisst, muss der Programmierer erst wieder in den Flow eintauchen.

Versuche, dein Team so „entspannt“ wie möglich zu halten. Eine gute Arbeitsumgebung erlaubt es, dem Programmierer sich auf das zu konzentrieren, wofür er da ist. Programmieren. Das Hauptproblem beim Flow ist, dass man wahnsinnig schnell aus dem Flow wieder herausfliegt. Ein Anruf und der Programmierer hat verkackt. Er liest dann lieber Blogs wie diesen hier oder wuselt bei Twitter herum. Versuche ALLES, um den Coder das ruhigste Umfeld aller Zeiten zu geben.

Werden die besten existierenden Werkzeuge benutzt, die man kriegen kann?

Mit nur einem einzigen Monitor kann kein Programmierer arbeiten. Mindestens die Ansicht auf den Code und die Ansicht auf den Projektplan sind notwendig. Der Programmierer kann nicht ständig zwischen Code und Ansicht hin und herschalten. Ein Programmierer oder Designer kann auch mit Microsoft Paint ein Icon malen, es geht aber einfacher mit Photoshop oder Gimp. Veraltetete Betriebssysteme sollen ermöglichen, Software für neue Systeme zu schreiben? Das funktioniert so nicht. Ganz schlimm ist, wenn die Festplatten voll laufen oder wenn man nach einem bekackten USB-Stick fragen muss.

Hast Du Tester?

Grundsätzlich solltest du anstreben, zu jedem Programm einen Test zu schreiben. PHP bietet mit PHPUnit eine Umgebung, die die Logik deines Programmes auf Fehler überprüfen kann. Der Klassiker ist zum Beispiel das Abfangen von negativen Werten in Eingabefeldern. Ein Test kann das von vornherein abfangen. Lerne Unit-Test-Tools kennen und versuche auch, Test-Driven-Development zu leben. Und tatsächlich ist bei mir genau diese Frage ein ganz klares NEIN. Ich teste viel zu selten.

Demonstrieren Job-Bewerber ihr Programmier-Können in einer nachvollziehbaren Art und Weise während des Bewerbungsgesprächs?

Ein Maler muss malen können. Das zeigt er beim Probearbeiten. Ein Programmierer sollte in seiner Bewerbung Codeschnipsel mitgeben. Noch idealer ist es, wenn dein Programmierer beim Einstellungstest ein nicht zu einfaches Problem lösen soll. Ich musste damals zum Beispiel ein Programm schreiben, das in jeder Ecke des Bildschirms einen kleinen schwarzen Kasten malt. Das kann man über fiese HTML-Tabellen lösen, von mir wurde aber CSS erwartet.

Gibt es den Flur-Test?

Um eine gute Benutzeroberfläche zu haben oder um sicherzustellen, dass das Programm einfach so funktioniert und vor allem nachvollziehbar ist, sollte dein Team sich irgendwen vom Flur krallen, der noch nie was mit dem Programm zu tun hatte. Damit stellst du sicher, dass der Programmierer, der das Ding versteht, eine einfache Lösung gebastelt hat. Mach das mit 5-6 Leuten und du lernst 95% von dem, was gute Benutzeroberflächen ausmacht.

Bitte lies den original-Artikel von Joel Spolsky. Der Artikel ist einfach nur geil!

Photoquelle

Magst du, was du liest? Dann lass mir doch eine Spende da.


Alternativen zu WhatsApp in Unternehmen - der eigene Chatserver Der Joel Test - 12 Stufen zu besserem Code
Lesezeit: 10:33 Minuten
1  

Diese Website nutzt Cookies. Inder Datenschutzerklärung steht, was mit deinen Daten hier passiert… Hab ich verstanden