Der Joel‐Spolsky‐Test für die Webentwicklung

Softwareentwicklung ist eine diffizile Geschichte. Noch immer scheitern viele Projekte oder verzögern sich unendlich, und kein Beteiligter weiß exakt, woran das liegt.

Ein Indikator für die Qualität der Umgebung, in der Software entstehen soll, ist der Joel‐Test: Zwölf simple Fragen, die man sich oder den Verantwortlichen stellen sollte, um den Ist‐Zustand zu bewerten und den Soll‐Zustand kennenzulernen: Zwölf Mal Ja.

Joel Spolsky hat seine Fragen schon vor Jahren in seinem Blog formuliert, und sie sind — zumindest in der informierten englischsprachigen Developer‐Gemeinde — legendär geworden. Seine Feststellung ist simpel: Wenn eine Softwarefirma in diesem Test mit weniger als 11 Ja abschneidet, hat sie ein Problem. Trotzdem finden sich immer wieder Firmen, die nur auf zwei oder drei Ja kommen.

Das Problem mit den Originalfragen ist: Sie passen prima auf Szenarien, in denen Entwickler irgendeine Art von Software produzieren, die kompiliert, verpackt und installiert wird und auf mehreren unterschiedlichen Betriebssystemen oder Betriebssystemversionen laufen soll. Dieses Szenario existiert natürlich — für Entwickler, die sich mit Webanwendungen beschäftigen, sind einige Fragestellungen allerdings nicht ganz so exakt beantwortbar. Außerdem bleibt die Welt ja nicht stehen, sondern entwickelt sich weiter. Eine angepaßte und für Webprojekte in meinen Augen sehr brauchbare Version hat unlängst Brandon Savage formuliert. Ich nehme mir die Freiheit, die Testfragen hier in Deutsch zu publizieren — vernünftige Umgebungsbedingungen für erstklassige Softwareentwicklung können nie schaden.

Der Joel‐Test für Webentwicklung

Im Schnelldurchlauf:

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

Diese zwölf Fragen sollten sich in sehr kurzer Zeit mit Ja oder Nein beantworten lassen, um zu wissen, wo man steht.

Ein paar Detailanmerkungen zu jeder einzelnen Frage:

1. Existiert eine Form von Versionskontrollsystem?

Es gibt hier keine Ausrede für ein Nein. Schon wenn man nur als Einzelperson an einem Projekt arbeitet, hat man Bedarf für die Features von Versionskontrolle: Beliebig ältere Dateiversionen wiederherstellen zu können, oder zumindest nachzusehen, was früher mal drinstand. Und das, ohne dass man in einer Flut von „filename.html.old“ ertrinkt.

Erst recht ist Versionskontrolle für die Teamarbeit unverzichtbar, denn erst damit ist es schmerzlos möglich, dass verschiedene Entwickler gleichzeitig an denselben Dateien arbeiten, ohne sich gegenseitig ihre Änderungen zu überschreiben.

Es gibt so viele kostenlose Lösungen: Subversion als der de‐facto Standard für zentrale Versionskontrolle (wer noch mit CVS arbeitet, nutzt ein nicht mehr zeitgemäßes Tool und sollte auf Subversion umsteigen — aber das ist immer noch besser, als nichts), oder Git, Mercurial oder Bazaar für die dezentrale Versionskontrolle (alle drei können auch in Kombination mit Subversion eingesetzt werden).

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

Das berührt die Frage: Wie kommt der geschriebene Code denn eigentlich auf den Server? Antwort: Indem jemand die geänderten Dateien hochspielt und irgendwie parallel auch die Veränderungen in der Datenbank vornimmt? Böse Falle! Der Prozess ist fehleranfällig und aufwendig. In Wirklichkeit will man einfach irgendwo einen Knopf drücken oder ein Programm starten, und alles notwendige passiert automatisch.

Aber eine neue Version wird ja nicht einfach so blind auf den Server geworfen: Vorher müssen Tests laufen, die neue Version wird vermutlich erstmal durch die Qualitätskontrolle geschleust (auf einem separaten Server nur für die QA‐Leute). Insgesamt hat es einen deutlich beschleunigenden und fehlerreduzierenden Effekt, wenn der Aufwand, die Software auf den Server zu tun, möglichst gering ist. Man denke nur an den nötigen Aufwand, einen komplett neuen Server erstmalig in Betrieb nehmen zu müssen.

3. Wird Continuous Integration benutzt?

Continuous Integration ist der Prozess, dass sämtliche Arbeit der Entwickler fortwährend in das Gesamtprojekt einfließen, und dass sofort geprüft wird, ob eine Änderung irgendetwas kaputt macht. Für diese regelmäßige Aufgabe existieren Tools wie phpUnderControl oder Xinc, die sämtliche Code‐Änderungen im Versionskontrollsystem einer eingehenden Prüfung unterziehen: Unit‐Tests ablaufen lassen, die Einhaltung von Coding‐Standards prüfen, quantitative Qualitätsmerkmale ermitteln, automatische Dokumentation generieren etc. — und sofort Alarm zu geben, wenn irgendeiner dieser Schritte scheitert. Denn es ist am einfachsten, sofort zu reagieren, wenn die Erinnerung der Entwickler noch frisch ist, wenn eine Änderung irgendetwas kaputt macht.

4. Gibt es eine Bug‐Datenbank?

Keine Frage: Ein Entwickler sollte seine geistige Kapazität ausschließlich für das Coden bereithalten, nicht zum Erinnern an irgendwelche Bugmeldungen. Und er sollte diese Bugmeldungen auch nicht in einem unübersichtlichen Mailarchiv hervorsuchen müssen.

Bug‐Datenbanken, oder auch Issue‐Tracker genannt, sind der ideale zentrale Ort, in dem sich alle Meldungen über Merkwürdigkeiten, Bugs, neue Features etc. befinden. Es gibt viele kostenlose Systeme wie Trac (das integriert gleich noch ein Wiki und einen Browser für den in der Versionskontrolle gehaltenen Code), Mantis oder Bugzilla. Diese sind als Minimal‐Erfüllung der Frage vollkommen in Ordnung. Aber es gibt auch etliche deutlich mächtigere Systeme, die für Geld zu lizensieren sind, und die Verwaltung und das Management des Projekts deutlich leichter machen. Egal, was installiert würde: Die Abwesenheit einer Bug‐Datenbank ist unentschuldbar.

5. Werden Fehler gefixt, bevor neue Features geschrieben werden?

Je mehr Zeit vergeht, bevor ein gefundener Fehler behoben wird, desto aufwendiger wird es. Angenommen, ein Entwickler baut einen Tippfehler ein. Wenn ihm der Compiler oder Interpreter sofort eine Fehlermeldung auswirft, dauert es keine fünf Sekunden, und der Fehler ist weg. Wenn der Tippfehler subtiler ist, und erst nach dem Commit das Continuous Integration‐System das Scheitern eines Unit‐Tests meldet, dauert das Beheben schon länger — der Code muss erst wieder gefunden und gelesen werden. Wenn eine Woche vergeht, bevor der Entwickler die Bugmeldung bearbeitet, ist die Erinnerung an seine Absichten in dem Code schon verblasst. Er muss sich erst wieder reindenken, was er erreichen wollte.

Und die Situation wird natürlich nicht einfacher, wenn zwischendurch der fehlerhafte schon durch neue Features verändert wurde. Im Gegenteil: Mit Pech verlässt sich irgendein anderer Codeteil mittlerweile auf das falsche Verhalten. Oder es wurden viele Entwicklerstunden verbraten, weil der Fehler zu unerklärlichem Verhalten führte. Egal, was es ist: Fehlerhaftem Code kann man nicht trauen — spätestens wenn der Fehler an Kunden ausgeliefert wird, und der ihn entdeckt, sinkt das Vertrauen in die Qualität des Produkts.

6. Gibt es einen immer aktuell gehaltenen Plan?

Der Plan sollte die Frage beantworten: Was passiert als nächstes? Und zwar für das gesamte Team sichtbar. Entwickler mögen keine Überraschungen, vor allem keine unangenehmen. Wenn unerwartet in drei Tagen die Fertigstellung wichtiger Features auf den Plan kommt, wirft das die gesamte interne Planung jedes einzelnen Entwicklers über den Haufen.

Zwar kann der Plan nicht in Stein gemeißelt werden, er muss flexibel sein und sich sowohl an den Projektfortschritt als auch die wandelnden Erfordernisse und Kundenwünsche anpassen. Aber in gewissen Punkten muss er verlässlich sein: „In den kommenden zwei Wochen realisieren wir die Features A, B und C“ wäre eine einfache Ansage und klärt gleichzeitig, dass sich nicht mit Features D und E beschäftigt wird.

7. Gibt es Spezifikationen?

Mit Spezifikationen sind nicht die 500‐Seiten‐Dokumente gemeint, die sowieso keiner liest. Aber eine irgendwie fixierte Feststellung, was eigentlich genau gewünscht ist und hergestellt werden soll. Eine Skizze eines Seitenlayouts, eine stichpunktartige Liste von Methoden, eine kurze Beschreibung einer zu realisierenden Schnittstelle.

Soezifikationen klären, was genau zu tun ist — bevor man es tut. Durch Spezifikationen können Entwickler den Umfang der Aufgabe abschätzen. Außerdem verhindern sie, dass sich im Laufe der Erledigung die Aufgabe ständig um neue Features erweitert (feature creep) oder der Kunde in letzter Minute noch „wichtige Änderungen“ haben will. Wenn eine Spezifikation vor dem Start abgesegnet ist, ist klar, dass die Aufgabe erledigt ist, wenn alle Punkte wie spezifiziert realisiert wurden. Das bedeutet nicht, dass z.B. der Kunde nichts ändern kann — nur nicht einfach so während der Aufgabenerledigung mit der Erwartung, dass dann trotzdem alles zum gleichen Zeitpunkt fertig wird.

8. Haben die Programmierer eine ruhige Arbeitsumgebung?

Programmieren ist eine extrem anstrengende Tätigkeit, die hohe Konzentration verlangt. Höchstleistungen erbringen Programmierer immer erst, nachdem sie sich eine gewisse Zeit, vielleicht zehn Minuten oder eine Viertelstunde, auf das Problem konzentriert haben und idealerweise in den „Flow“ kommen. Jede äußere Störung, sei es durch Telefon, schwatzende Kollegen, hereinkommende Mails etc., unterbricht den Arbeitsfluß, stört den Flow, und senkt die Qualität und Produktivität.

Auch wenn Programmieren im Prinzip Teamarbeit ist: Die Möglichkeit, sich ungestört in ein Büro zurückzuziehen, ist unbezahlbar.

9. Werden die besten existierenden Werkzeuge benutzt, die man kriegen kann, und wird auch Geld für die Werkzeuge ausgegeben, die notwendig und teuer sind?

Entwickler sind verhältnismäßig teuer von den Betriebskosten her. Deshalb gibt es keine Entschuldigung, ihre Produktivität zu senken, indem unzulängliche Werkzeuge benutzt werden müssen.

Ein vernünftiger Rechner, der in der Lage ist viele Programme gleichzeitig geöffnet zu haben, nicht hakelt oder endlos mit der Festplatte rödelt? Zwingende Voraussetzung. Zwei angeschlossene Monitore? Das ist kein Luxus, das hebt die Produktivität um 20 bis 30%. Funktionierende Peripherie wie Tastaturen und Mäuse, eine vernünftige Softwareentwicklungsumgebung (IDE), … all das sind elementare Grundbedürfnisse zur Erfüllung der Arbeit.

Im Prinzip muss das Arsenal von Werkzeugen in der Lage sein, dem Entwickler zu keiner Zeit störend im Weg zu stehen — denn auch das stört den Flow. Im Gegenteil drückt die Investition in hochwertige Werkzeuge die Wertschätzung aus, die den Entwicklern entgegengebracht wird (natürlich auch im negativen Sinn).

10. Werden Unit‐Tests geschrieben?

Continuous Integration funktioniert nur, wenn Probleme und Fehler innerhalb von kürzestmöglicher Zeit durch automatisierte Verfahren entdeckt werden. Und zentraler Bestandteil solcher automatisierten Verfahren sind Unit‐Tests.

Viele Projekte funktionieren ohne Unit‐Tests. Meist deshalb, weil manuelle, menschliche Tester checken, ob die Software irgendwo kaputt ist. Oder die Entwickler werfen ein Auge drauf und bemerken auftretende Probleme. Dummerweise ist manuelles Testen nie so gründlich, weil es eine sehr langweilige Aufgabe ist, dieselben Prüfungen immer und immer wieder vorzunehmen. Deshalb sind automatisierte Tests ein sehr wichtiger Faktor zum Heben der Qualität. Je weniger Fehler unentdeckt bleiben, desto stabiler wird die Software, und desto mehr Zeit steht den Entwicklern für die Herstellung neuer Features zur Verfügung.

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

Joels Originalfrage war: Schreiben Bewerber während des Bewerbungsgesprächs Code? Das ist eventuell etwas zu konkret und speziell. Ohne Frage ist es für den Arbeitgeber notwendig, die Fähigkeiten des Bewerbers einschätzen zu können — konkret das Schreiben von Code liefert aber nicht zwingend ausreichende Hinweise.

Stattdessen sollte das Gespräch flexibler und am Bewerber orientiert sein: Einem Berufsanfänger stellt man andere Aufgaben, vielleicht tatsächlich konkret die Programmierung einer einfachen Funktion, als einem auf dem Papier mit langjähriger Erfahrung ausgestatteten Entwickler. Mit dem diskutiert man vielleicht lieber die grundsätzliche Umsetzung kniffliger Probleme. Insgesamt sollte aus dem Gespräch die Erkenntnis gewonnen werden, wie der Bewerber denkt, wie er Probleme löst, und wie er kommuniziert.

12. Gibt es Tester?

Zweifellos wird Software immer noch von Menschen benutzt, und deshalb sind menschliche Tester unverzichtbar für einen guten Softwareentwicklungsprozess. Testern kommt dabei eine sehr wichtige Rolle zu: Sie müssen einerseits in die Rolle des Endusers schlüpfen und die Verständlichkeit der Benutzerführung etc. prüfen, andererseits aber auch fachliches Wissen der Programmierer haben, um zu erkennen, mit welchen potentiell problematischen Testszenarien sie Fehler im Programm provozieren können. Und sie müssen am Ende ihre Resultate auch noch in verständlichen und das Problem ausreichend beschreibenden Meldungen dokumentieren.

Die Entwickler sind hingegen ganz schlechte Tester. Einerseits wissen sie, was sie programmiert haben, und damit voreingenommen. Andererseits ist ihre Aufgabe, zu programmieren, und nicht zu testen. Vor allem wenn der Zeitplan eng ist, ist die Versuchung groß, das Testen einfach zu kürzen oder ganz wegfallen zu lassen.

Eigenständige Tester, die in der Lage sind, den Finger auf wunde Stellen zu legen, und denen die Kompetenz zugesprochen wird, ihr Veto zu einer geplanten Veröffentlichung einzulegen, wenn die Software nicht ordentlich funktioniert oder die Spezifikationen nicht erfüllt, sind ein sehr wichtiger Team‐Bestandteil.

Unter dem Strich

Diese Anforderungen (mindestens mit dem Fokus auf weborientierte Software), die eine gute Arbeitsumgebung für Softwareentwicklung auszeichnen, sollten im Prinzip überall realisiert werden, wo Software geschrieben wird. Wie erwähnt: Microsoft und ähnliche Top‐Kaliber haben 12 von 12 Ja — die ganze Zeit. Sehr gute Firmen laufen mit 11/12. Ab 10/12 wird es laut Joel kritisch.

Die Fragen sind einfach genug, dass man sie sich in fünf Minuten selbst beantworten kann. Und alle Punkte mit „Nein“ sollten so bald wie möglich geändert werden, dass ein „Ja“ dabei rauskommt.

Kommentare nehme ich natürlich sehr gerne entgegen.

12 Kommentare » Schreibe einen Kommentar

  1. Herrschaften, geht’s noch? Dieses Blog zu spammen mit Pseudo‐Kommentaren führt zu nix. Wir sind vielleicht tot, aber nicht blöd.

  2. Hallo an alle! Bei der Entwiockung der Webseite http://www.example.com konnten wir oft auf diese Webseite zurückgreifen. Dafür möchten wir uns herzlich bedanken! Alles Gute weiterhin, wir werden Sie noch sehr oft besuchen!

  3. Ups… nun werde ich nochmals richtig in mich gehen! Ich dachte ich schnapp mir YAML, Djang und git und los geht es.

    Danke auch an iGel für die Bestättigung bzgl. git!

  4. @rpr:
    Ich arbeite mit Subversion und Git (wobei ich inzwischen fast alle Projekte auf der Arbeit auf Git an SVN‐Server umgestellt habe). Beide sind nicht schlecht, aber insgesamt hat Git (für mich) sehr viele Vorteile. Insbesondere Branchen und Mergen funktioniert einfach so gut, dass man es immer macht — Ich mache es teils sogar für 1‐Tages‐Features. Bei SVN funktioniert insbesondere das Mergen von Branches nicht so gut, daher vermeidet man Branchen oft ganz (ich musste mehrfach alles per Hand kontrollieren, weil SVN versagt hatte). Uns ist deswegen gerade wieder eine Änderung online gegangen, die noch nicht sollte, weil derjenige aufs Branchen für eine 14‐Tage‐Änderung verzichtet hat.

    SVN ist oft natürlich noch besser eingebunden in die IDEs. Aber TortoiseGit steht TortoiseSVN nicht mehr nach und zusehends mehr IDEs können Git vernünftig ansteuern (Wobei ich sowohl bei SVN als auch Git alles über die Konsole committe). Und gitk (bzw. gitx auf dem Mac oder gitg auf Linux) vermisse ich jedes Mal schmerzlich, wenn ich wieder mit SVN arbeiten muss.

    Man sollte Git (oder Mecurial/Bazaar) mal bei einem Projekt ausprobieren. Wem es nicht gefällt, kann ja immer noch zurück.

    Unit‐Test: Die müssen natürlich gewartet werden. Bei Rails bin ich inzwischen auf Test‐Driven‐Development umgestiegen. Das ersetzt natürlich keine manuellen Tests, verhindert aber, dass einmal gemachte Fehler (für die man Tests geschrieben hat) nochmal macht.

    Tests schreiben braucht Erfahrung, aber dann geht es recht schnell. Und der Entwickler muss da auch hinterstehen, sonst testet mal halt irgendwas, aber nichts sinnvolles. Wenn man einmal ein ordentliches Testframework hat, kann man auch bei Code, den man selbst länger nicht angefasst hat oder den jemand anderes programmiert hat, sehr viel sicher sein, dass man mit den neuen Änderungen nichts kaputt macht. Von meinen Kollegen höre ich hingegen öfters: Nee, dass fass‘ ich nicht mehr an, das fällt alles auseinander.

  5. Sehr schöner Artikel!

    In meiner Umgebung wird sehr viel Wert auf die Trennung von Entwicklungssystemen und Produktiven Systemen gelegt. Es gibt da auch den berühmten „Knopf zum Produktiv Schalten“ und einheitliche Prozesse.

    Eine kleine Anmerkung zum Punkt 8: Es ist sicher individuell unterschiedlich, bis ein Programmierer in den Flow kommt, 15 Minuten erscheinen mir jedoch etwas kurzgefasst. Cheffe sollte auf jeden Fall Verständnis dafür haben, wenn es etwas länger dauert, umso flotter geht dann die Tipparbeit.

    –Rolf

  6. Ersteinmal Danke für die Übersetzung und danke für das Thema. In der Theorie scheinen diese Punkte ja funktionieren zu können aber in der Praxis wohl eher nicht. Nichtmal in großen Softwareunternehmen ist es möglich, geschweige den in kleineren, eine „ruhige Arbeitsumgebung“ zu finden. Die Bug‐Datenbank ist ein guter Ansatz, ohne Zweifel, dennoch müssen die Bugs auch gefixt werden, gerade dann, wenn Features anstehen. usw.… am Ende testet doch irgendwie wieder der Kunde das Produkt, denn nicht umsonst gibt es den Spruch „Das Produkt reift beim Kunden“…

  7. Hi, RPR!

    • Subversion ist das zeitgemäßeste Tool für zentrale Versionskontrolle. So steht das auch im Text, wird aber vielleicht ungünstig durch den lästernden Einschub über CVS überdeckt. CVS funktioniert zwar im Grunde auch, hat aber diverse nervige Eigenarten, die man sich nicht mehr geben sollte.
    • Ein‐Schritt‐Deployment: Dokumentation ist natürlich gut, aber wenn man dann immer noch hundert Einzelschritte erledigen muss, in der richtigen Reihenfolge, unter Beachtung von Zwischenschrittergebnissen, dann ist das Verfahren trotzdem zu aufwendig, um es beliebig häufig fehlerfrei wiederholen zu können.

      Sowas fällt nicht über Nacht vom Himmel, der automatisierte Deployment‐Prozess entwickelt sich. Und bietet dann — so meine mindeste Hoffnung für das Projekt, in dem ich gerade involviert bin — wieder Raum für diverse Nettigkeiten, die man noch obendrauf haben kann.

    • Wo du Eclipse erwähnst: Das Plugin PTI (PHP Tools Integration) bietet auf extrem nette Weise die Integration von PHP CodeSniffer (für direktes Feedback zur Einhaltung der Coding‐Styles) und PHP Unit (direktes Starten von UnitTests bzw. Generieren von Testcases) in der IDE. Prädikat: Empfehlenswert.

      Das reicht für Continuous Integration aber nicht aus. Denn man will so schnell wie möglich wissen, ob die eigene Änderung am Code funktionierend mit den Veränderungen zusammenpaßt, die die Kollegen in der Zwischenzeit getätigt haben.

      Die Tatsache, dass man wissen will, wenn irgendwas unabsichtlich kaputtgemacht wurde, hat nichts mit dem Szenario zu tun, dass man bei umfassenden Änderungen willentlich was kaputt macht, um dann alles, was auf die Änderung negativ reagiert hat, in einem zweiten Arbeitsschritt aufzuarbeiten. Augenmaß und Kommunikation sind wichtig.

    • Das Thema UnitTests ist heiß diskutiert, vor allem in Fachkreisen. Und man braucht schon eine gewisse Erfahrung mit dem Schreiben testbarer Software, um dieses Tool wirklich gewinnbringend einzusetzen. Ich habe da schon einige Dinge gesehen, die man zwar „Test“ nennen konnte, die aber wirklich allen Richtlinien der „reinen Lehre“ widersprachen, die mir bekannt sind — nur um am Ende eine tolle Prozentzahl „Code Coverage durch Tests“ vermarkten zu können.
  8. Netter Artikel, vielen Dank! 🙂

    Ein paar Anmerkungen noch dazu:

    • Subversion ist kein „geht gerade noch so“-Tool, der Eindruck wird hier erweckt. Nicht jeder braucht eine dezentrale Versionskontrolle; es gibt hier Vor‐ und Nachteile je nach Umgebung. Außerdem ist das Tooling für Subversion derzeit noch IMHO um einiges besser als für die dezentralen.
    • One‐Click‐Installation: Es genügt, wenn der Prozess dokumentiert und einfach ist; eine Versteifung auf einen Schritt halte ich für übertrieben und — wenns doch mal Schwierigkeiten gibt — ggfls. sogar für kontraproduktiv. Bitte mal den Blick über den PHP‐Einfach‐Anwendung‐Suppenteller heben.
    • Continous Integration: Eine moderne IDE wie Eclipse checkt das Projekt bei jedem Save auf Fehler; genügt das? Ich kenne, Fälle, in denen das Continous Integration Team ständig anderen Entwicklern auf den Sack ging, weil diese bei einem größeren Umbau mal für 5 Minuten den heiligen Build zerschossen haben.
    • Unit‐Tests: Sicher immer gut, aber keine Blanko‐Versicherung: Die meisten (nicht‐trivialen) Fehler passieren nun mal in komplexen Umgebungen und genau das deckt ein „Unit“-Test eben nicht ab; hier sind andere „Vorgehensweisen“ (oder Tools) gefragt. Weiterhin habe ich die Erfahrung gemacht, dass viele Unit‐Tests nichts taugen (testen das falsche (die API) und keine Grenzfälle, werden nicht aktualisiert, …); also wie gesagt: Immer gut, aber mit Verstand verwendet und immer ergänzt für die „Nicht-Unit“-Sachen.
  9. Sehr schöner Artikel. In der Realität werden (leider) die meisten IT‐Firmen mit 5/12 antworten (Ehrlichkeit vorrausgesetzt).

  10. Danke für die Übersetzung.

    Bisher hatte ich noch kein Projekt, dass groß genug war, dass sich der Aufwand lohnt, aber wenn ich was Größeres mache oder im Team arbeite, werde ich mir diese Punkte zu Herzen nehmen.