Systemarchitektur: Softwareentwicklung ist kein binärer Entscheidungsbaum

Schwarz-weiß denken in der Softwareentwicklung

Für viele Probleme der Softwareentwicklung und Umsetzungen gibt es sinnvolle Prinzipien, Design-Pattern und Leitlinien. Allerdings sollte man verstehen, welche Probleme dieses Lösen wollen, statt diese starr einzusetzen.

Hinweis: Dieser Artikel ist keine Argumentation für Entwickler die unsauber arbeiten, und Prinzipien, die sie nicht verstehen, einfach ignorieren wollen.

1. Ich (versuche) Code so zu schreiben, dass ein anderer ihn versteht. Auch mein zukünftiges selbst ist ein anderer, denn er wird nicht mehr wissen, warum ich dieses oder jenes gemacht hast.
2. Ich baue etwas nur flexibel, wenn die Anforderung dafür da ist (oder ich wirklich, wirklich erwarte das diese kommt). Sonst baue ich eine Abstraktion die bei jeder Arbeit am Projekt nur die eigentlichen Sachen die passieren verschleiern, ohne dass ich einen Gewinn davon habe.
   
   1. Man tauscht in seinem Projekt nicht Maria DB gegen Postgresql aus, verzichte daher auf unnötige Abstraktionen.
   2. Ich kann nicht von Vorhinein eine Facade anlegen, welche für alle zukünftigen Adaptionen funktioniert, ohne dass ich die zukünftigen Anforderungen kenne. Daher lege ein Interface (z.B. für Ausgabeformate) erst beim zweiten Format an.
3. Interfaces
   1. Für Repositories gilt, dass ich ein Interface benötige, was sagt, was ich benötige, die Implementierung beinhaltet das wie. Zudem kann ich in den Tests das Repository über das Interface mocken.
   2. (Application) Services sind konkret, daher bekommen sie kein Interface. Ändert sich die Buisness Logik, änder diese ihr Verhalten auch.
   3. Dasselbe gilt für Entities
4. Ich baue iterativ. Nicht alles muss man im ersten Entwurf des Programms strukturieren. Das ist besonders dann nötig, wenn es sicherlich noch Rückfragen an den Project Owner geben wird.
   
   1. Funktional
      
   2. Prozedural/Kapseln (Hier kann man schon Tests anlegen)
   3. Modular
   4. Objektorientiert, Strukturiert
   5. Design-Pattern
5. Ich baue eine Prozessstruktur (Primary Tasks) nicht auf Events, solange es keinen Fall gibt der diese Events erweitert oder die Reihenfolge der Events ändert. Events werden für nur für "Secondary Tasks" eingesetzt. (Hinweis auf Book review: Object Design Style Guide von Matthias Noback).
6. Ich versuche nicht, etwas beim ersten Mal perfekt zu bauen. Denn dann brauche ich bei jeder Richtungsänderung meiner Implementierung viel Zeit die Details anzupassen. Wichtig: Das heißt aber auch, dass ich nach einer lauffähigen Implementierung immer einmal aufräumen (refactoring) muss.

Baue keine Autobahn, so lange du nicht weißt ob der Bedarf da ist, denn sonst hast du bei einer Anpassung der Streckenführung viel Arbeit.

Diese Überlegungen bedeuten für mich, dass ich immer, wenn ich etwas ein zweites/drittes Mal anfasse, schauen muss, ob jetzt der Zeitpunkt für ein Interface ein Design-Pattern oder das Abtrennen einer Funktionalität gekommen ist. Daher baue dann iterativ um. Die Kunst hier ist es, dann auch so Professionell zu sein, dass auch zu machen. Das unterscheidet einen guten Softwareentwickler von einem Frickler ;)

All die bekannten Regeln und Prinzipien, wie SOLID, versuchen dem (unerfahrenen) Entwickler Hilfen an die Hand zu geben, solange Sie die negativen Auswirkungen ihres Codes nicht selber erkennen können. Wenn Sie selber in der Lage sind diese Regeln zu formulieren, sollten Sie diese nicht mehr starr anzuwenden, sondern das Problem Ihrer Umsetzung bewerten und dann entscheiden.

Article release date: (24.03.2020) / Last update: (02.01.2022)