Software – Hauptsache es läuft…

Immer wieder höre ich den Satz von Entwicklern und Chef’s: “Hauptsache das Programm läuft…”. Inzwischen reagiere ich ziemlich allergisch gegen diese Aussage und versuche dann auch prompt den Leuten zu erklären, warum es nicht genügt, dass ein Programm einfach nur läuft. Häufig mit mässigem Erfolg. Ich versuche in diesem Post aber aufzuzeigen, was ich darüber denke, wie Softwareentwicklung funktionieren muss.

Schlüsselfaktoren für eine langfristig gute und qualitativ hochwertige Software sind:

  • Kommunikation zwischen den beteiligten Personen (Projektleiter, Entwickler, Kunde)
  • Automatisierung wo es nur geht -> Continuous integration
  • Stimmung / Motivation im Team -> Der Wille sich ständig verbessern zu wollen
  • Abdeckung der Software durch Tests -> Unit Tests, Integration Tests, …
  • Kontinuierliches Refactoring -> Die Software ändert sich schliesslich immer
  • Regelmässige Code Reviews
  • Modularer und unabhängiger Aufbau der Softwarekomponenten

Es ist zwar etwas zusammengewürfelt, aber ich möchte einfach noch ein paar Gedanken zu den oben aufgezählten Punkten erwähnen.

Wenn das Programm läuft ist man nur halb fertig

Wenn man glaubt, das man mit einer Funktion fertig ist, hat man normalerweise etwa die hälfte geschafft (ausser man entwickelt mit TDD, da ist’s besser)Wenn bei uns die Lehrlinge jeweils sagen, dass sie fertig sind, frage ich sie:

  • Ist der Code dokumentiert?
  • Ist der Code mit Tests abgedeckt?
  • Hat jemand ein Review von deinem Code gemacht?
  • Hast du den Code schon refaktorisiert bzw. aufgeräumt?
  • Läuft es auch auf einer anderen Installation?

Natürlich ist die Antwort eigentlich immer nein (wahrscheinlich wie bei den meisten Entwicklern). Man sollte sich also auch unter Zeitdruck immer fragen, ob die Aufgabe auch wirklich erledigt ist. Niemals sollte man sich damit zufrieden geben, dass es einfach nur läuft, auch wenn einem dies jemand anders so vermitteln will.

Modularer Aufbau von Software

Inzwischen bin ich der festen Überzeugung, dass Software modular aufgebaut und in kleine Teile unterteilt sein sollte. Viele kleine Legosteine, welche keine Abhängigkeiten haben, sind viel einfacher zu einem ganzen zusammenzufügen, also grosse und undurchschaubare Konstrukte. Zwei wichtige Prinzipien sind hier Separation of Concern und Dependency Inversion Principle.

Testen

Immer wieder höre ich, dass z.B. Unit Testing nur Zeit benötigt und eigentlich gar nicht soviel bringt. Diesem Punkte kann ich absolut nicht zustimmen. Testing ist etwas absolut essentielles.

Schreibe ich Tests, formuliere ich meine Anforderungen an die Funktion. Ausserdem stelle ich sicher, dass meine Architektur im kleinen gut ist (bei zu vielen Abhängigkeiten wird es schwierig überhaupt zu testen). Zudem muss ich keine Angst vor Refactorings haben. Aussagen wie diese gibt es nicht mehr: “Ich mach mal lieber nichts an dieser Funktion, ich weiss ja nicht, ob sie nachher noch funktioniert”.

Refactoring

Refactoring ist immer wieder nötig, da sich die Software auch ständig ändert. Wer kein Refactoring macht, sondern alles an das Bestehende anhängt, wird über kurz oder lang einen riesen Krüppel generieren.

Code Reviews

Code Reviews haben mehrere Vorteile. Man kann mit anderen kommunizieren und so auch seinen Horizont erweitern. Ausserdem sieht jemand anders häufig Fehler oder unklare Konstrukte, die einem so nie aufgefallen wären.

Zusammenhang zwischen Code Reviews, Modularität, Testing und Refactoring

Die Zusammenhänge ergeben sich eigentlich von alleine. Um gute Software, sprich unabhängige, modulare Software zu produzieren, muss man sie mit Tests abdecken. Da sich Software ständig ändert, muss sie Refaktorisiert werden, ohne Tests ist dies nicht ohne Fehler möglich. Die Code Reviews unterstützen diesen Prozess.

6 Responses

  1. Leider kenne ich diese Aussage auch zur Genüge. Was mich aber interessiert: Wie kann man diesen Aussagen mit Fakten entgegentreten? Was antworten wenn einer zu einem sagt: “Funktioniert doch”? Wie kann ich meinen Kollegen die Prinzipien von CCD auf einfache Weise vermitteln?

  2. Ich versuche es einfach vorzuleben. Ich hole die Jungs, die ich überzeugen möchte auch öfters zu mir und zeige Ihnen dann Beispiele (vielleicht nerve ich sie ja auch, weiss ich nicht 🙂

    Refactoring:
    – Zeigen von Code vor und nach dem Refactoring

    Unit Testing:
    – Zeigen, wie ich einen Fehler einfacher finden kann, wenn ich Unit Tests habe
    – Zeigen, wie ich ein einfaches Refactoring machen kann, wenn ich Unit Tests habe

    Ich glaube, wenn man das lange genug macht, kann man die meisten überzeugen, dass dies einen positiven Nutzen hat.
    -> Steter Tropfen höhlt den Stein

  3. Hey Ralph, merci für deinen tollen Artikel. Hatte den letzthin schon mal gesehen und war froh, diesen nun noch einmal zu finden. Deine Aussagen treffen zu, und es erfreut mich, dass du dies auf so wenige Worte runterkürzen konntest. Es gibt natürlich noch viele weiteren Dinge, die beim Durchschauen von Code interessant sind: Gibt es Hardcodings? Wird der Code immer durchlaufen, oder gibt es toten Code? Datenbanken: Was passiert, wenn sich das Schema ändert, neue Spalten hinzukommen?

    Es wäre cool, wenn du hierüber auch mal einen Artikel schreiben könntest!

    Liebe Grüsse
    Gregor

  4. Hi Gregi

    Danke für Dein Feedback. Freut mich, dass es Dir gefallen hat!
    Ich habe mir mal die Punkte notiert, die Du erwähnt hast und werde, wenn ich mal die Zeit bzw. Lust finde, auch einen Artikel zu diesen Themen schreiben.

Leave a Reply

Your email address will not be published. Required fields are marked *