Softwarekomplexität in den Griff bekommen
-
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.
-
Das ist bei kleinen .NET/Java/Ruby Klitschen sogar sehr oft der Fall. Wenn man J2EE halbwegs richtig macht, hat man durch das Framework schon mehr oder weniger automatisch eine Architektur und wenn man sich mit dem Framework auch auskennt, dann programmiert man auch selber so ähnlich und verwendet schon viele Patterns. Bei Ruby auch so ähnlich. Vor allem ohne MVC kommt man da nicht weit, im Gegensatz zu vielen (zumindest älteren) PHP Projekten.
-
Fakt ist doch das Software mindestens 1 mal neu geschrieben werden muss, wenn man eine gute Softwarearchitektur haben will. Die erste Version ist zum Lernen.
-
knob schrieb:
Fakt ist doch das Software mindestens 1 mal neu geschrieben werden muss, wenn man eine gute Softwarearchitektur haben will. Die erste Version ist zum Lernen.
Gerade als Anfänger sollte man in der Praxis Disziplin einhalten oder sich strikt an die Vorgaben der Firmenleitung (sofern vorhanden) halten!
Welche Firma kann es sich leisten, dass ein Mitarbeiter seine Arbeit häufig wegschmeissen und neu machen muss? 
Das Lernen obliegt dem Mitarbeiter selbst!
-
LOLAlter schrieb:
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
Also da steht für mich jetzt kaum was neues drin und ich bin weit davon entfernt ein toller Software-Architekt oder Designer zu sein. Vieles davon habe ich unbewusst schon immer umgesetzt, auch wenn mir die ganzen tollen Begriffe wie Open-Closed-Principle kein Begriff waren.
Was mir am meisten hilft, ist das Bottom-Up-Prinzip bei der Planung. Ich plane eh nicht bis ins kleinste Detail, aber es hilft, wenn man weiß was auf JEDEN Fall gemacht werden muss. Beispiel: Eine Kamera soll später Bilder für die Software liefern.
Damit ist doch schon klar, es muss eine allgemeine Schnittstelle für die Kamera geben ,falls die Kamera doch mal getauscht werden soll usw. usf. und dann hangelt man sich eben in der Planung hoch
-
Ich vermute dass nach derzeitigem Stand ein Bottom-Up-Konstruktionsprinzip für eine gute Architektur genauso vorhanden ist wie ein Konstruktionsprinzip für mathematische Beweise.
Es gibt ein paar Rahmenbedingungen und "gute Vorgehensweisen", aber damit hat sich's dann.
-
Ich kenne zwei Bücher zur Ausgangsfrage, die sind ganz gut. Kein Allheilmittel, aber einen Blick wert:
Large-Scale C++ Software Design von
John Lakosund
- Game Coding Complete von Mike McShaffry
Außerdem hilfts vielleicht, wenn man sich direkt an größeren Programmier-Projekten im Internet beteiligt, die Freiwillige willkommen heißen. Hier wird man Praktiken begegnen, welche die Komplexität - oder besser das Chaos (in eingeübter Weise) eingrenzen.
...und...Arbeitsplan/Protokollierung, Evaluierung.
...und (ich könnte) mit dem Finger auf andere größere Projekte zeigen, die immer mal wieder scheitern. (Es gibt dazu auch Textmaterial, welches sich mit den Gründen des Scheiterns auseinandersetzt, das mag auch ein wenig weiterbringen)Ein Buch, das sich einwenig ums Mißlingen dreht, hat zwar nicht direkt mit Programmierung zu tun, ist aber auch einen Blick wert, wenn auch zweitrangig. An erster Stelle steht das nah am Plan bleiben und Protokollieren und Evaluieren:
"Die Logik des Mißlingens. Strategisches Denken in komplexen Situationen von
Dietrich Dörner.
Für die Softwareseite spielt auch noch weniger ist mehr eine Rolle, aber das ist wohl im beschriebenen Zusammenhang etwas zu ideal. Guten Code muß man erstmal am Vorbild gesehen haben - und man muß auch tiefschürfendes Know How haben um den Code ökonomisch in "schmalen Strukturen" hinzubekommen.
