Da ich mich seit der Ausbildung sehr für gute Softwarearchitektur interessiere, habe ich mal überlegt, welche aus meiner Sicht die häufigsten konzeptionellen Probleme zu sein scheinen. Also Aspekte, die eine Weiterentwicklung oder intensivere Nutzung der Anwendungen dann unnötig erschweren.

Es soll dabei gar nicht um so generelle Aspekte (mangelndes OOP, keine Patterns, …) oder Tool & Sprachen bashing (Java benötigt mehr Code als Python, …) gehen, sondern um sehr viel grundlegendere Dinge, welche fast schon unabhängig von der Implementierung sind. Geordnet nach Häufigkeit, hier also die (IMHO) common pitfaults:

Keine 1:n Beziehung

Oft fehlt einfach die Unterstützung von mehr als einer einzigen Zuordnung. So gibt es multi-homes ebens, wie multi-Organisationen, oder mehreren Vorgängern usw.

Keine zeitliche Dimension

Dies spielt nicht nur bei den Datenmodellen rein (timestamps, Versionerung, logs), sondern betrifft auch in den Entwicklungsprozess. Es wird fast nie nur die eine Version 1.0 ausgerollt, sondern die Software hat einen Lebenszyklus. Die Algorithmen, Datenmodelle und Speicherstrukturen (DBs, Dateien, …) verändern sich dabei ebenso, wie APIs Protokolle und Metadaten. Entwicklung ist eben ein kontinuierlicher Prozess und dieser sollte auch durch Endnutzer und Administratoren ohne Probleme verfolgbar sein.

Lose Kopplung, aber um was zu tun?

Gerade in Java werden viele Projekte mit unzähligen UML-patterns aufgebaut. Das ist zum einen zu begrüßen, setzt aber bei allen (neuen) Entwicklern auch die Kenntnis der damit abgebildeten Abläufe voraus. Damit geht leider unweigerlich auch eine deutliche Komplexitätssteigerung einher (in Daten und Kontrollfluss) und oft wird der Zweck der Nutzung (lose Kopplung, Austauschbarkeit, …) gar nicht mehr wahrgenommen bzw. nicht ausgenutzt.
Klar, Muster dienen einem konkreten Zweck und sollten da eingesetzt werden, wo Planung / brainstorming auch Potentiale erkennt. Doch auch dank guten Werkzeugen und Techniken (TDD, CI) ist auch späteres refactoring kein Hexenwerk.

Überspezifikation statt Pragmatismus

Ein Problem, was mir sehr oft gerade bei öffentlichen Projekten (XÖV, Bundeswehr, …) begegnet, ist ein sehr langer Designprozess, an dessen Ende eine extrem umfangreiche Spezifikation steht. Wie im Punkt zuvor wird zu viel Aufwand und Gedanken an eine perfekte Version 1.0 gesteckt, anstatt Agile Entwicklung zu betreiben und die mehreren Phasen der Entwicklung kontinuierlich zu wechseln und in kleinen Schritten voran zu kommen. Auf diesem Kurs kann dann auch kontinuierlich nachreguliert werden, womit der Änderungsaufwand klein bleibt und die Gefahr an den Anforderungen vorbei zu entwickeln, fast Null ist.

Existierende Alternativen

Oft scheint nicht geprüft zu werden, welche ähnlichen Softwareprojekte vorhanden sind und wieso diese die Anforderungen (nicht) erfüllen. Schreitet dann die Entwicklung fort, kann nicht mehr erklärt werden, warum man sich früher zu einer Neuentwicklung entschloss und wieso man später keine Zusammenführung der Projekte anstrebte, bzw. man prüfte ob auch Komponenten (Bibliotheken und frameworks) nachnutzbar sind.

Zusammengefasst

Klar, ich bin auch bei weitem nicht perfekt und wahrscheinlich tapse ich auch öfters in vermeidbare Fehler. Allerdings habe ich mir angewöhnt die hier genannten Aspekte aber zumindest im Hinterkopf zu behalten und bei Konzeptionen nochmal gezielt darauf zu achten. Ob man immer best-practise fahren kann / sollte hängt sicherlich von vielen Faktoren ab. Benutzt man einen Objekt-relationalen-Mapper für die Persistenz und hat eine Testsuite mit sehr guter Abdeckung, kann man sicherlich Umbauten etwas gelassener entgegen schauen. Wenn alles händisch gestrickt ist und Umbauten viel Arbeit machen, sollte man schon eher über solche Stolperfallen nachdenken… Denn oft rächen sich diese gerne nach einigen Jahren, wenn die Software bereits bei Endnutzern ausgerollt ist und diese damit schon lange gearbeitet haben.