Softwarekomplexität in den Griff bekommen
-
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.
-
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!
