Wie wir bauen: fünf Praktiken für wartbare Software

Ob eine Anwendung in zwei Jahren noch wartbar ist, entscheidet sich nicht am Releasetag, sondern in den Gewohnheiten, mit denen sie entsteht. Viel Software scheitert nicht an einem dramatischen Fehler, sondern an tausend kleinen Abkürzungen, die irgendwann niemand mehr überblickt. Wir verlassen uns deshalb nicht auf Heldentaten, sondern auf Handwerk. Fünf Praktiken bilden dabei das Fundament, unabhängig davon, ob wir mit Microsoft-Technologien oder mit Open Source bauen.

Fünf Praktiken

1. 01

   Domain-Driven Design

   Wir schneiden Software entlang eurer Fachlichkeit statt entlang technischer Grenzen, und wir benutzen dieselben Begriffe wie ihr. So spiegelt der Code eure Domäne wider, bleibt für Team und Technik gleichermaßen verständlich und lässt sich auch in Jahren noch sinnvoll erweitern.

2. 02

   Test-Driven Development

   Wir entwickeln testgetrieben, damit die Software die Anforderungen nachweislich erfüllt und auch nach Änderungen zuverlässig bleibt. Tests sind dabei Sicherheitsnetz und Dokumentation zugleich: Sie sagen, was die Software können muss, und schlagen Alarm, wenn eine Änderung etwas Bestehendes bricht.

3. 03

   Versionskontrolle und Continuous Integration

   Jede Änderung ist nachvollziehbar, und die Software ist jederzeit auslieferbar. Automatisierte Pipelines bauen und testen bei jeder Änderung und fangen Fehler früh, statt sie in die Produktion durchzulassen, wo sie teuer werden.

4. 04

   User-Driven

   Eure Benutzer:innen sind von Anfang an eingebunden, nicht erst beim Abnahmetermin. Was entsteht, passt zu ihrem Alltag und wird deshalb genutzt.

5. 05

   Agil

   Wir arbeiten iterativ und transparent, mit regelmäßigen Reviews statt einem großen Wurf am Ende. So bleibt die Richtung jederzeit korrigierbar, und ihr seht früh, was entsteht, statt monatelang auf eine Blackbox zu warten.

Wie die Praktiken zusammenspielen

Einzeln ist keine dieser Praktiken neu, ihre Wirkung entsteht im Zusammenspiel. Domain-Driven Design gibt der Software eine Sprache, die Tests aus dem Test-Driven Development überhaupt erst sinnvoll formulierbar macht. Continuous Integration sorgt dafür, dass diese Tests bei jeder Änderung laufen, statt in Vergessenheit zu geraten. Der User-Driven-Ansatz stellt sicher, dass wir das Richtige bauen, und das agile Vorgehen, dass wir früh merken, wenn nicht. So stützt eine Praktik die nächste.

Wartbarkeit ist kein Feature, das man später nachrüstet. Sie entsteht in den Gewohnheiten des Bauens.

Keine dieser Praktiken ist spektakulär, und genau das ist der Punkt. Zusammen sorgen sie dafür, dass eure Lösung auch dann noch trägt, wenn das Projektteam längst weitergezogen ist und neue Anforderungen dazukommen. Und sie sind die Voraussetzung dafür, dass wir euch am Ende eine Lösung übergeben können, die euer Team selbst weiterentwickelt, statt von uns abhängig zu bleiben. Wie das in ein Projekt eingebettet ist, zeigt Was wir tun.