Softwarekomplexität in den Griff bekommen

inflames2k

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.

Mechanics

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.

berniebutt

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 Lakos

und

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.