Design/Architektur von Software (wie macht man es richtig?)



  • Hallo Leute,

    Hat jemand ein paar Tipps für mich, wie ich Software am besten strukturieren/designen kann? Oder kann jemand Literatur hierfür empfehlen?

    nun... ich habe Elektrotechnik studiert und habe daher keine guten Bedingungen eine größere Software von Grund auf richtig zu entwickeln. Ich habe unter anderem C++ aus interesse heraus gelernt und weil man das im Studium (je nach Studiengang) in einem gewissen Maß benötigt. Seit fast 2 Jahre arbeite ich nun an einer Software die zwar funktioniert, aber noch weiter wächst. Die ist aus einigen wenigen experimentellen Funktionen heraus entstanden und weißt nun einen recht großen Umfang vor. Nach einem Plan oder einem Entwurf wurde nicht programmiert und so ist die innere Struktur nicht unbedingt optimal.

    Seit Beginn sind nun meine Programmierfähigkeiten gewachsen und ich habe diverse Bücher gelesen ("effektives modernes C++", "Entwurfsmuster", ...). Nun möchte ich meine Software gerne Restrukturieren und diverse Mängel bzw. Anti-Pattern beseitigen (es sind einfach zu viele). Allerdings fühle ich mich noch etwas Hilflos. Mit UML habe ich noch nie wirklich gearbeitet, aber ich denke es ist der erste Schritt für die Verbesserung.

    Mein Plan ist jetzt folgender: Ich möchte die Software irgendwie als Modell abbilden, nach der ich strukturiert arbeiten kann. Nur fehlt mir der Einstieg bzw. die Vorgehensweise. Wie mache ich das am besten? Gibt es gute Bücher dazu? Wie designt ihr größere Software? ...Habt ihr bestimmte Muster bei der Vorgehensweise?

    viele Grüße,
    SBond



  • Als Einstieg (mit vielen weiteren Links):
    https://de.wikipedia.org/wiki/Prinzipien_objektorientierten_Designs

    Du musst nicht gleich alles umsetzen, aber das gibt Ideen.
    Fang dort an, wo Du denkst dass deine Anwendung am meisten profitiert.

    Hast Du Tests für deine Anwendung?
    Falls nein wäre es eine Überlegung wert diese einzuführen, und zwar bevor Du alles umschreibst.
    Denn so stellst Du sicher das Du im Verlauf des Umschreibens nicht allzuviel kaputtmachst.



  • SBond schrieb:

    Hat jemand ein paar Tipps für mich, wie ich Software am besten strukturieren/designen kann? Oder kann jemand Literatur hierfür empfehlen?

    Das Problem ist vielleicht, das es nicht "DAS" Design bzw. "DIE" Architektur gibt. Es hängt sehr viel von Faktoren wie Projektgröße, Komplexität, Aufgabenstellung usw. ab. Es gibt z.B. Architekturmuster, Methoden/Ansätze die je nach Fall besser oder schlechter geeignet sind. Und alles fällt mit einer schlechten IDE (wenn eine IDE träge ist oder sinnvolle funktionalitäten fehlen und nicht nachgerüstet werden kann, wird man notwendige Maßnahmen nicht durchführen - und ich weiß hier wovon ich spreche).

    Für OOP kann ich dir als grundlegende Prinzipien GRASP und SOLID nennen.

    Weitere Aspekte könnten sein Entwurfsmuster, Enterprise Application Architecture Pattern, Themen wie Refactoring, Test Driven Development, Behavior Driven Development, Domain Driven Design...

    Die Auswahl ist riesig und es gibt nicht einen Ansatz der für alle Fälle optimal ist. Auch mal sinnvoll zum stöbern ist meines Erachtens der Blog von Robert C. Martin, nur sollte man da schon etwa wissen wonach man suchen will.



  • Bei der Software-Entwicklung ist das Programmieren das Einfachste. Eine Programmiersprache und ein paar APIs kann jeder schnell lernen und auch erfolgreich anwenden.

    Für Software-Architektur braucht meiner Meinung und Erfahrung nach mind. ein Jahrzehnt. Weil selbst das Bücherlesen einem nicht weiter hilft, man muss selber die Erfahrung in Projekten machen, wie man es nicht macht. Um dann zu verstehen, warum es diese ganzen Architektur-Empfehlungen gibt.

    Schön und gut wenn man sich die SOLID Priziepen durch gelesen hat. Aber warum weiß man in Wirklichkeit nicht. Das weiß man erst, wenn man im Projekt eine God-Klasse ändern soll, oder harte Abhängigkeiten umgehen soll. 😃

    Aber die Hinweise sich SOLID und GRASP als Startpunkt anzuschauen, ist richtig und wichtig! Bis man diese Punkte nämlich in Fleisch und Blut hat, wird einige Zeit dauern. 🙂



  • Artchi schrieb:

    Schön und gut wenn man sich die SOLID Priziepen durch gelesen hat. Aber warum weiß man in Wirklichkeit nicht. Das weiß man erst, wenn man im Projekt eine God-Klasse ändern soll, oder harte Abhängigkeiten umgehen soll. 😃

    Wobei in Büchern wie "Clean Code" recht gut die Gründe gezeigt werden (Eigene Erfahrung ersetzt das aber niemals).



  • vielen Dank für die Infos 🙂

    Wie ich das so lese ist das scheinbar eine Erfahrungssache. SOLID und diverse andere Prinzipien sind mir soweit aus Büchern bekannt. Ich werde versuchen das beste daraus zu machen.

    Auch nochmal danke für die Hinweise und Links 🙂

    wünsche euch ein schönes Wochenende 😃



  • SBond schrieb:

    Hat jemand ein paar Tipps für mich, wie ich Software am besten strukturieren/designen kann?

    Willst Du strukturieren und designen oder restrukturieren und refaktorieren? Ist ja nicht das Gleiche. Auto Bauen ist ja auch nicht das Gleiche wie Getriebe Wechseln, während das Auto fährt 😃



  • ähhh... also ich will die Softwarearchitektur ändern.
    Vom klobigen Softwareklotz in eine schöne modulare Software à la SOLID. Zumindest wage ich den Versuch und es ist scheinbar nicht so trivial 😞 . Wäre schön wenn man sich im Laden eine Packung Erfahrung kaufen könnte, aber die Literatur gibt zumindest gutes Input. Das selbstständige Anwenden seht jedoch immer auf einem anderen Blatt und von den SOLID-Prinzipien hat meine Software leider noch nie was gehört.

    Naja.... wird schon...



  • D.h. Design und Code ändern, ohne das Verhalten der Software zu ändern. Das ist ein Refactoring.

    Es gibt die Möglichkeit die Software-Entwicklung pausieren zu lassen und das Refactoring auf einmal durch zu ziehen. Je nach Größe der Software kann das ja bis zu mehrere Monate dauern. Das wird aber wohl ein Kunde/Inhaber kaum bewilligen, und das wird auch kein Entwickler sich trauen, außer er mag auf dem Schleudersitz sitzen, weil das bestimmt schief gehen wird. 😃

    Also bleibt nur die zweite Möglichkeit: das Refactoring an der Software Schritt für Schritt machen. Die Code-Bereiche die man eh gerade anfasst (Bugfix, neue Funktionen einbauen usw.) einem Refactoring unterziehen. Dabei aber auch gleich Unittests schreiben, wenn es keine gibt.

    So wird zwar das Redesign der Architektur etwas dauern, aber es wird ein viel kleineres Risiko. Denn iterativ kann man auch rechtzeitig reagieren.


Log in to reply