Ein Datenimport läuft seit einiger Zeit. Nun soll eine zusätzliche Regel gelten: Fehlt in einer Zeile eine benötigte Zuordnung, darf diese Zeile nicht ungeprüft übernommen werden. Für Sie als Auftraggeber klingt das nach einer kleinen Änderung. Ob sie überschaubar bleibt, hängt davon ab, wie die Anwendung aufgebaut ist und wie sich ihr Verhalten prüfen lässt.
An diesem beispielhaften Änderungswunsch lässt sich Wartbarkeit greifbar machen: Sie zeigt sich daran, wie nachvollziehbar und sicher spätere Änderungen durchgeführt werden können. Entscheidend ist, ob die fachliche Regel auffindbar ist, ihre Auswirkungen erkennbar sind und bisher benötigtes Verhalten erhalten bleibt.
Eine kleine Regel berührt einen ganzen Ablauf
Zunächst muss die neue Regel fachlich geklärt werden. Welche Zuordnung ist erforderlich? Soll nur die betroffene Zeile zurückgestellt oder der ganze Import angehalten werden? Welche Meldung hilft Ihnen, den Fall zu bearbeiten? Diese Fragen bestimmen das gewünschte Verhalten, bevor der Code geändert wird.
Dann muss erkennbar sein, wo die Prüfung hingehört. Wenn Einlesen, fachliche Bewertung und Speichern unterscheidbare Aufgaben sind, lässt sich die Regel einem passenden Schritt zuordnen. Steht dieselbe Regel dagegen an mehreren Stellen, muss jede davon gefunden und auf ihre Bedeutung geprüft werden.
Klare Zuständigkeiten im Code sind deshalb eine Arbeitshilfe: Sie zeigen, welcher Teil eine Datei versteht, welcher über gültige Angaben entscheidet und welcher Daten dauerhaft speichert. Eine kurze Erklärung einer ungewöhnlichen Regel kann dabei ebenso hilfreich sein wie ihre technische Trennung.
Tests machen erwartetes Verhalten überprüfbar
Ein automatisierter Test führt einen festgelegten Fall aus und vergleicht das Ergebnis mit einer Erwartung. Für unsere beispielhafte Änderung wären mindestens zwei Fälle interessant: eine Zeile mit vollständiger Zuordnung und eine Zeile ohne diese Angabe. Hinzu kommen bestehende Fälle, deren Verhalten sich durch die Änderung nicht verschieben soll.
Auch das Verhalten nach einem Fehler verdient Aufmerksamkeit. Wurden schon Daten gespeichert? Ist erkennbar, welche Zeilen übernommen wurden? Kann der Vorgang erneut gestartet werden, ohne unerwünschte Doppeleinträge zu erzeugen? Welche dieser Fragen relevant sind, hängt vom vereinbarten Importablauf ab.
Tests ersetzen diese fachlichen Entscheidungen nicht. Sie halten ausgewählte Erwartungen überprüfbar fest. Ihr Nutzen hängt davon ab, ob sie wichtige Fälle abdecken und ob die Erwartungen noch zur tatsächlichen Aufgabe passen. Ein erfolgreicher Testlauf beweist keine allgemeine Fehlerfreiheit.
Was mein internes Projekt eur_ledger daran zeigt
In meinem internen Referenzprojekt eur_ledger ist die Herkunft importierter Daten eine ausdrücklich beschriebene Regel. Beim erneuten Excel-Import wird eine unveränderte, bereits importierte Quellzeile übersprungen. Wurde dieselbe Quellzeile geändert, meldet die Anwendung einen Konflikt, statt den vorhandenen Datensatz stillschweigend zu überschreiben. Gleiche Beträge allein reichen dabei nicht als Nachweis einer Dublette.
Damit ist eine Entscheidung auffindbar, die bei einer späteren Änderung erhalten oder bewusst angepasst werden muss. Der zuvor beschriebene Wunsch nach einer zusätzlichen Zuordnungsprüfung ist ein erklärendes Beispiel, keine Behauptung über eine weitere vorhandene Funktion von eur_ledger.
Ein dokumentierter Fehlerfalltest des Projekts betrachtet einen anderen, klar abgegrenzten Ablauf: Eine Eingangsrechnung und ihre Zahlungsinformation werden gemeinsam vorbereitet. Tritt vor dem gemeinsamen Speichern ein Fehler auf, prüft der Test, dass nach erfolgreicher Rücknahme keine der beiden neuen Änderungen dauerhaft gespeichert bleibt. Es geht um Zahlungsinformationen, nicht um das Auslösen einer Banküberweisung. Dieser Nachweis gilt für den geprüften gemeinsamen Ablauf und darf nicht auf sämtliche Importmodi übertragen werden.
In meiner Entwicklung halte ich solche Regeln und Entscheidungen ausdrücklich fest. Zugleich unterscheide ich den erreichten Stand vom Zielbild: Die Trennung fachlicher und technischer Teile ist in eur_ledger teilweise umgesetzt; einzelne Berichte greifen noch direkt auf die Datenbanksitzung zu. Die Referenz beschreibt damit auch offenen Weiterentwicklungsbedarf. Eine Zielarchitektur ist kein Nachweis, dass bereits jede Stelle der Anwendung diesem Aufbau entspricht.
Ein Hilfsskript braucht einen passenden Rahmen
Ein bewusst begrenztes Skript für einen einmaligen, kontrollierten Vorgang kann angemessen sein. Wenn Eingaben überschaubar sind, das Ergebnis vollständig geprüft werden kann und die Folgen eines Fehlers begrenzt sind, muss daraus keine umfangreiche Anwendung werden.
Anders ist die Ausgangslage bei Software, die regelmäßig läuft, wichtige Daten verändert oder von mehreren Personen weiterentwickelt werden soll. Dann gewinnen erkennbare Zuständigkeiten, dokumentierte Regeln und wiederholbare Prüfungen an Bedeutung. Eine kurze Entwicklungszeit sagt für sich genommen wenig über die Qualität aus. Problematisch wird es, wenn ein provisorischer Umfang dauerhaft genutzt wird, ohne seine Grenzen erneut zu prüfen.
Fragen, die Sie als Auftraggeber stellen können
Auch ohne den Quellcode im Detail zu lesen, können Sie eine geplante Änderung mit konkreten Fragen begleiten:
- Wo ist die betroffene fachliche Regel beschrieben, und welche Teile der Anwendung verwenden sie?
- An welchen Beispielen wird die Änderung geprüft, einschließlich ungültiger Eingaben und Fehlerfällen?
- Wie wird erkennbar, ob bisher benötigte Funktionen weiterhin arbeiten?
- Was geschieht bei einer unterbrochenen Verarbeitung, und wie kann ein Ergebnis kontrolliert werden?
- Welche bekannten Grenzen bleiben bestehen, und was muss bei der nächsten Änderung berücksichtigt werden?
Aussagekräftige Antworten beziehen sich auf Ihre Anwendung und den tatsächlichen Änderungsumfang. Die bloße Anzahl von Tests oder ein Architekturdiagramm beantwortet diese Fragen noch nicht.
So viel Struktur, wie die Aufgabe begründet
Wartbarkeit entsteht durch Entscheidungen, die spätere Arbeit verständlich und überprüfbar machen. Der dafür eingesetzte Aufwand muss zu Lebensdauer, Änderungsbedarf und den Folgen eines Fehlers passen. Nicht jede denkbare Erweiterung muss vorweggenommen werden; wichtige Regeln und Grenzen sollten jedoch erkennbar sein.
Wenn Sie eine bestehende Anwendung erweitern oder einen begrenzten ersten Umfang entwickeln möchten, erläutert die Seite Individuelle Softwareentwicklung mein Vorgehen. Beschreiben Sie Ihren konkreten Änderungswunsch – in einem Gespräch lässt sich klären, welche Regeln, Abhängigkeiten und Prüfungen dafür wichtig sind.