Softwarekomplexität in den Griff bekommen
-
Hi!
Ich habe einen Bachelor in Informatik und gerade mein erstes Master-Semester im selbigen Fach "hinter mich" gebracht. Während des Studiums hatten wir diverese kleinere Projekte für Vorlesungen (im Umfang von 6 Wochen bis zu 2 Monaten) in welchen wir Software für bestimmte Bereiche schreiben sollten (z.B: Client/Server oder eingebettete ARM Systeme). Bei diesen Projekten fiel mir immer wieder auf, dass alle Studenten in der Gruppe Probleme damit bekommen habe, wenn die Komplexität der Software stieg. Da ich nebenebei noch an der Uni gearbeitet habe, ist mir gleiches auch bei den Forschungsprojekten aufgefallen:
Zu Beginn eines Projektes ist der Code noch sauber, gepflegt, übersichtlich und vielleicht sogar dokumentiert. Nach 2-3 Wochen ist man froh, wenn Änderungen an einer Stelle nicht den Rest des Programms abschießen. Die Gründe dafür sind sicherlich verschieden: Angefangen über mangelnde Absprache / Kommunikation in der Gruppe, über schlechte / gar keine Dokus bis hin zu unbekannten / unentdeckten Quer-Abhängigkeiten.
Gibt es Tips/Tricks/Tools/Bücher, die aus praktischer Sicht darauf eingehen, wie man die Komplexität eines Software-Projektes in den Griff bekommt? Man findet ja realtiv viel zum Thema Projektmanagement, aber dort geht es dann immer eher um Themen wie "Definieren Sie genaue Ziele" oder "Sprechen Sie wichtige Entscheidungen mit dem Team ab". Nach sowas suche ich nicht.
Ich habe momentan etwas Zeit und starte in den nächsten Wochen ein kleineres Home-Projekt. Dieses Projekt würde ich gerne so aufziehen, wie man es auch bei einem "großen Projekt" tun würde. Also mit GIT/SVN, Wiki, Doku, evt. Milestones, Bugtracker etc. Hinzukommt dann natürlich noch eine (intelligente) Software-Architektur. Mir würden da spontan ein paar Entwurfsmuster für bestimmte Probleme einfallen. Vielleicht gibt es auch hier eine Art "Übersicht" über gängige Muster zur Software-Strukturierung?
Für all sowas muss es doch ein Anfangspunkt zum Einlesen geben, oder?Ich hoffe Ihr wisst, was ich meine - ich habe da irgendwie Schwierigkeiten das in Worte zu fassen.
Gruß
Pille
-
Ich befürchte hier benötigt es vor allem Erfahrung, ansonsten kann man sich natürlich versuchen aktiv an bekannte Principles zu halten, also bspw.: SOLID, DRY, etc.
MfG SideWinder
-
Pille456 schrieb:
Zu Beginn eines Projektes ist der Code noch sauber, gepflegt, übersichtlich und vielleicht sogar dokumentiert. Nach 2-3 Wochen ist man froh, wenn Änderungen an einer Stelle nicht den Rest des Programms abschießen. Die Gründe dafür sind sicherlich verschieden: Angefangen über mangelnde Absprache / Kommunikation in der Gruppe, über schlechte / gar keine Dokus bis hin zu unbekannten / unentdeckten Quer-Abhängigkeiten.
Saubere Interfaces definieren und mit unit tests absichern.
-
Schau dir mal das Thema Software Engineering etwas näher an. Sicherlich hattet ihr das auch im Studium gehabt, selbst im BIM Studium hatte ich das. Eines der wenigen Sinnvollen Dinge die ich da mitgenommen habe.
Vielleicht hiflt dir auch das Werk Software-Architektur kompakt von Gernot Starke und Peter Hruschka. Dort wird beschrieben mit welchen Methoden man Herr solcher Komplexität wird. Doch auch wie meine Vorredner bereits gesagt haben, am wichtigsten ist Erfahrung und da hilft es anfangs auch mal auf die Nase zu fallen.
-
Vorausschauend planen und Disziplin beim Programmieren! Einfache Regel: lokale Aenderungen sollen nur lokale Auswirkungen haben.
Vielleicht gibt es auch hier eine Art "Übersicht" über gängige Muster zur Software-Strukturierung?
Ich dachte, du studierst Informatik?
Also mit GIT/SVN, Wiki, Doku, evt. Milestones, Bugtracker
Wie soll das Spaghetti-Code verhindern?
-
Hey!
Danke für Eure Tips. Leider hatte ich schon befürchtet, dass es mehr um Erfahrung geht, die man sich nicht aus Büchern / HowTos aneignen kann.
knivil schrieb:
Ich dachte, du studierst Informatik?
Ja, aber leider ist dieses Themengebiet eher stiefmütterlich behandelt worden. Zumal die meisten Themen im Bereich der Softwarekonstruktion irgendwie eher theoretischer Natur waren (Metamodelle, Homomorphismen, Software als Algebra usw.)
knivil schrieb:
Wie soll das Spaghetti-Code verhindern?
Gar nicht. Dafür muss man schon als Programmierer sorgen. Dennoch hilft es ja bei der Verwaltung oder nicht? Ich weiß es nicht, habe sowas noch nie benutzt, darum frage ich ja...
-
Nun, mein "Geheimtipp" wäre hier: Komplexität vermeiden.
Versuchen, die Implementierung simpel zu halten. Selbstverständlich ist das nicht immer möglich. Komplexe Probleme erfordern oft komplexe Lösungen. Ich meine jedoch viel eher Dinge wie: nicht dazu hinreißen lassen, große Mengen Code zu schreiben, um Features zu implementieren, die eigentlich nicht benötigt werden.
Einfachheit nicht für minimale Verbesserungen in Bedienbarkeit oder Aussehen opfern.
Und insbesondere: Komplexität aufteilen. Damit meine ich nicht nur auf verschiedene Module aufteilen, sondern auf verschiedene Programme. Muss die gewünschte Funktionalität denn unbedingt in einem Programm implementiert werden? Könnte man stattdessen nicht mehrere simplere Programme schreiben? Ein kleines Programm zu einer Perle zu polieren, ist oft einfach.
Außerdem: keine Duplizierung der Funktionalität anderer Programme oder des Betriebssystems. Einfach ein vorhandenes Programm aufrufen, anstatt irgendwas halbgares selbst zu implementieren.
-
Pille456 schrieb:
Zu Beginn eines Projektes ist der Code noch sauber, gepflegt, übersichtlich und vielleicht sogar dokumentiert. Nach 2-3 Wochen ist man froh, wenn Änderungen an einer Stelle nicht den Rest des Programms abschießen. Die Gründe dafür sind sicherlich verschieden: Angefangen über mangelnde Absprache / Kommunikation in der Gruppe, über schlechte / gar keine Dokus bis hin zu unbekannten / unentdeckten Quer-Abhängigkeiten.
Tja, mit so etwas:
Man findet ja realtiv viel zum Thema Projektmanagement, aber dort geht es dann immer eher um Themen wie "Definieren Sie genaue Ziele" oder "Sprechen Sie wichtige Entscheidungen mit dem Team ab". Nach sowas suche ich nicht.
Wäre das nicht passiert.
Wenn das Ziel gut definiert ist, dann sollten unerwartete Quer-Abhängigkeiten nicht zum Problem werden.
Es mangelt also an der Definition.Gibt es Tips/Tricks/Tools/Bücher, die aus praktischer Sicht darauf eingehen, wie man die Komplexität eines Software-Projektes in den Griff bekommt?
OOP + UML + Trennen in Module unter Nutzung von Schnittstellenspezifikationen.
-
Eins meiner privaten Projekte, an dem ich vor dem Studium gearbeitet habe, hatte auch schon grob 100 000 Zeilen Code und ich hab vier Jahre dran gearbeitet. Würde ich heute zwar als Spaghetticode betrachten, aber ich hatte es im Griff und musste nicht die ganze Zeit alles umbauen und schauen, was ich alles kaputtgemacht habe. Da seh ich jetzt nicht ganz ein, wie man im Studium schon bei 2-4 Wochen Projekten solche Probleme bekommt.
Ich hätte vom Studium erwartet, dass man etwas lernt, wie man sowas strukturiert angeht und durchzieht. Ich hätte gedacht, nach dem Studium würde ich sowas viel besser können. Kann ich auch, aber nicht direkt durch das Studium, gelernt haben wir in der Hinsicht leider nicht besonders viel. Ich kann mich hier SideWinder nur anschließen, hier hilft vor allem die Erfahrung. Das ist mir auch während dem Studium dann klar geworden, dass es hier nichts besonderes gibt, was man einfach lernen könnte um dann große Projekte sofort erfolgreich durchzuziehen.
Paar Architekturmuster und Prinzipien gibts hier aber natürlich schon. Entwurfsmuster kennst du schon, es gibt auch übergeordnete Architekturmuster, z.B. Domain Driven Design, MVC, Microkernel usw. Dann gibts natürlich grundlegende Prinzipien wie SOLID, hat hier schon jemand genannt. Das hilft dir ohne Erfahrung auch nicht unbedingt weiter, aber es ist sozusagen ein Pool an Überlegungen, die andere Leute schon zu ähnlichen Problemen angestellt haben und hilft bei der Orientierung.
Aber wenn ihr schon nach drei Wochen alles wegschmeißen wollts... Einfach nicht sofort mit dem Programmieren anfangen, sondern sich das Gesamtsystem vorstellen. Muss gar nicht so wahnsinnig detailliert sein, aber es sollte möglichst viele Anforderungen abdecken und sollte soweit erweiterbar sein, dass man Anforderungen, die vorher nicht so ganz klar waren, damit auch noch abdecken kann und nicht alles umbauen muss.
-
Progo schrieb:
OOP + UML
Hmm, mit diesen Begriffen verbinde ich aus Erfahrung eigentlich eher komplexe gescheiterte Monster von Systemen, die völlig weich nach irgendwelchen vermeintlichen "Best Practices" designt wurden. Meinst du das liegt nur daran, dass man bei derartigen Problemen eher zu OOP und UML neigt oder könnten letztere vielleicht auch ursächlich für solche Probleme sein?
-
buzzword-driven design schrieb:
Progo schrieb:
OOP + UML
Hmm, mit diesen Begriffen verbinde ich aus Erfahrung eigentlich eher komplexe gescheiterte Monster von Systemen, die völlig weich nach irgendwelchen vermeintlichen "Best Practices" designt wurden. Meinst du das liegt nur daran, dass man bei derartigen Problemen eher zu OOP und UML neigt oder könnten letztere vielleicht auch ursächlich für solche Probleme sein?
Das liegt doch auch wieder an der Erfahrung der SW Entwickler, die die SW in UML designen.
Erfahrene Entwickler wissen was geht und was nicht geht und die UML hilft dann das ganze zu visualisieren, damit behält man den Überblick.
Am Ende brauchst dann nur noch ordentliche Code, die das UML Zeugs dann implementieren, hier kann es dann auch wieder Leute mit zu wenig Erfahrung geben.Nichtsdesto trotz ändert das nichts daran, dass die UML ein Hilfsmittel für Leute ist, die damit umgehen können.
-
Zum Thema Softwarekomplexität kannst du dir mal dieses Paper von Robert C. Martin durchlesen.
Es bietet keine universellen oder umfassenden Weisheiten, versucht aber die Probleme zu benennen und liefert ein paar Stichworte zur weiteren Recherche.
http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf
-
-
Ich habe bis jetzt noch keine Software selbst angefangen zu schreiben, sondern kam immer in ein Team oder musste alte Software anpassen und/oder erweitern. Doku und Architektur ist bis jetzt immer sehr unzureichend gewesen. Kollegen von mir haben auch noch an keinem Projekt gearbeitet, wo irgendwas rund lief und was von vorne bis hinten durchdacht war.
Selbst OOP ist meist keine große Hilfe. Es hört sich in der Theorie immer alles ganz toll an, mit den Schnittstellen, Adaptern, Modulen, Unittests und einheitlicher Versionsverwaltung und Fehlerbehandlung. In der Praxis ist mir in den letzten 10 Jahren nix davon in großem Maße unter gekommen. Eher habe ich bis zum Tode normalisierten Datenbanken angetroffen und auch Überdesignte Software, wo kaum ein Mensch mehr durchblickt, was das Programm eigentlich macht.
Vielleicht habe ich nur Pech gehabt. Ich unterscheide mittlerweile auch zwischen Leuten die theoretisch über Softwareentwicklung quatschen und denen die wirklich täglich in den unterschiedlichsten Projekten stecken, also die, die wirklich die IT machen, anstelle drüber zu reden.
Frameworks und Libs zu nutzen, kann auch sehr übel enden. Das ist immer dann der Fall, wenn Funktionalität fehlt und nach gebaut wird, was dann aber meist das Framework nicht mehr updatefähig macht. Da wird dann über die Jahre auch richtig üble Software daraus.
Gute Softwarearchitektur kannst du nur erreichen wenn du extrem viel Erfahrung hast und damit meine ich nicht den akademischen Teil und wenn du von Anfang bis Ende mit dem Projekt verbunden bist. Alles andere ist meist ein Kampf.
-
Man muss bei der Softwareentwicklung unterscheiden zwischen:
1. Neuentwicklung eines Projektes
2. Pflege und Erweiterung bestehender Projekte
3. Gebrauchstestad 1. Hierzu gibt es viele nützliche Ansätze und Hilfen der Compiler
ad 2. Ist und bleibt immer ein besonders schwieriges Terrain
ad 3. Eine besonderes AufgabeFür alles braucht man Praxiserfahrung, die in der Theorie schwer zu vermitteln ist. Wenn Änderungen und Erweiterungen umfangreiches Umschreiben bestehender
Programmteile erfordern, dann stimmt das Konzept der Software nicht. Und gerade dafür wurde einmal OOP eingeführt.
-
Sind dir denn persönlich schon Projekte untergekommen wo das OOP/Qrchitektur ok war? Ich kann mir vorstellen, dass bei Frameworks das schon eher durchdacht ist, aber die meiste Software sind keine neuen Libs/Frameworks.
-
Ich kenne einige Projekt, wo die fehlerhafte Verwendung von OOP nicht das grösste Problem war, sondern Exception-handling, Logging, Kodierungen.
-
Es ist doch aber schon komisch. Ich habe auch schon Literatur über Softwarearchitektur, Design-Pattern und Projektmanagement gelesen, aber auch teilweise nur überflogen. Nie habe ich so etwas in der Praxis angetroffen, oder wenn dann nur in homöopathischen Dosen.
Alle labern nur darüber, aber keiner kann da wirklich was von in die Praxis bringen. Allein schon deswegen weil kaum ein Mitarbeiter von Anfang an dabei ist und wenn dann fehlt meist das Wissen um Softwarearchitektur, oder es ist auch einfach nicht das Geld dafür da. So ist jedenfalls mein Gefühl, ich sehe ja auch nur einen kleinen Teil des Kuchens.
-
Dann hast du noch nicht hinreichend Praxiserfahrung gesammelt... in vielen größeren Firmen (vorallem im Engineering) wird viel Wert auf Software-Architektur gelegt.
Vermutlich warst du in drei, vier Frickelbuden unter 20 Mann und meinst, jetzt etwas zu wissen.
-
Ich habe auch geschrieben, dass ich nur einen kleine Teil des Kuchens kenne. Und ja ich habe erst seit 13 Jahren Erfahrung in vier Buden gesammelt und kann nur von dem reden was ich wirklich erlebt habe. Meiner Meinung sind die meisten Softwarebuden auch eher kleine Firmen.
-
Nur sollte man nicht den Fehler machen und sagen, das es in jeder kleinen Softwarebude so abläuft. Bei uns im Unternehmen (16 Personen; 8 davon in der Softwareentwicklung, der Rest Verwaltung und Automatisierung) wird im Bereich Software ziemlich auf das Softwaredesign Wert gelegt. - Mein Abteilungsleiter sieht sich z.B. auch teilweise unseren Code an vorallem bei größeren oder wichtigeren Anwendungen. Und wenn ihm da mal etwas auffällt, was nicht OOP ist bzw. völlig gegen anständiges Softwaredesign geht, kann er auch schon einmal laut werden.
