Aus der Sicht des Projekt-Managements laufen die Dinge suboptimal, wenn man zü früh diverse Details der letztlichen implementatorischen Realisierung durchspricht. Zuerst sollte die Rahmen-Struktur des Projektes und des Produktes festgelegt sein.

 

So ist es z. B. ein großer Unterschied, ob man die fachlichen Dinge größtenteils vor der Implementation vorbereitet haben will und man damit eher bei einem geradlinigen Wasserfall-artigen Projekt-Modell landet oder ob man hochgradig agil operieren möchte oder ob man bezüglich bestimmter grundlegender Rahmen-Strukturen eher Wasserfall-artig und bezüglich des Ausfüllens der Rahmen-Strukturen mit Details z. B. mit dynamisch konfigurierbaren Plug-Ins eher agil arbeitet.

 

Für den Zugriff auf die erzeugten Materialien ist zuerst einmal ein Repository zur Versionsverwaltung erforderlich, wobei sich da Git besonders anbietet. Wenn niemand einen Server bereit stellen kann, auf dem Git installiert ist (was für einen Admin eine Kleinigkeit sein sollte), tut es auch ein öffentlicher Git-Server, wie z. B. github.com.

 

Ggf. ist ein zusätzliches Quell-Code-Review-System, wie z. B. Gerrit sinnvoll, wo die integrierenden Chef-Entwickler auf allzu großen Wildwuchs besseren Einfluß nehmen können.

 

Fachlich sollte man sich klar dazu bekennen, wie man die Aufwände statistischer Hypothesen-Bildung und -Verifikation im Vornherein (vor der Ausprogrammierung) und das Kontrollieren im Nachhinein mit Backtests bei Vorliegen des ausprogrammierten ATS aufteilen will.

 

Die Vorab-Analyse von Massen-Daten geht mit C/C++/Java-Programmen deutlich besser als mit spezialisierter Software für Handels-Systeme, da man damit keine Beschränkungen hat.

 

Sind die Datensätze wirklich groß, kann man problemlos auf Cloud-Cluster, wie z. B. Amazons EC2 ausweichen, statt ewig auf einen Leistungs-schwachen Heim-PC zu warten.

Bezüglich der Erwähnung der Nassi-Shneiderman-Diagramme sage ich mal, daß der heutige (leider bei weitem noch nicht überall akzeptierte) Standard spätestens seit dem Kult-Buch von Robert C. Martin Clean Code und der darauf folgenden ganzen Clean Code Development-Bewegung eher eine sehr exzessive Zerlegung der Funktionalität in viele sehr kleine Module ist. Damit bekommt man zwar sehr große und durchaus auch wieder zur Unübersichtlichkeit neigende Ansammlungen von Modulen, aber insgesamt kann man sie besser testen, abändern, systematischer dokumentieren und einiges mehr, welches aus Zeit-, Kosten- und Stabilitäts-Sicht im Software-Prozeß wichtig ist.

 

Sicher ist das Clean-Code-Buch schon recht extrem, aber ich teile in etwa 87 % seiner Ansichten. Ganz brachial überspitzt, soll demnach eine Funktion nur in etwa so komplex sein:

function top_function(args)
 if condition(args)
   then return sub_function_for_case_true(args)
   else return sub_function_for_case_false(args)

In dem Buch sind sehr viele gute und eher zu vermeidende Pattern zusammengefaßt.

 

Nassi-Shneiderman-Diagramme sollten im Normalfall nicht notwendig sein, da echter Bedarf an ihnen fast immer darauf hindeutet, daß der beschreibene Code zu komplex ist, daß er sich nicht mehr selber dokumentiert.

 

Manche Autoren sind sogar der (oft, aber nicht immer, auch zutreffenden) Ansicht, daß es keine kürzere sinnvolle Beschreibung für einen Programm-Ablauf gibt als das Programm selber und jedes zusätzlich erforderliche Dokument (insbesondere bzgl. der Programmierung im Kleinen, worauf sich Nassi-Shneiderman-Diagramme ja ausschließlich beziehen) von Übel ist.

 

Erst bei der Zusammenstellung von Modulen und Paketen bei der Programmierung im Großen, kommt man selten - auch bei bester Qualifikation aller Beteiligten - nicht um zusätzliche Entwurfs-Materialien herum. Die dort erforderlichen Darstellungen gehen aber weit über Nassi-Shneiderman-Diagramme hinaus und sind wie die Unified Modeling Language von einer nicht trivialen eigenen Komplexität, die meist komplexere Tool-Umgebungen erfordert, um wirkliche Produktivitäts-Vorteile zu bekommen.

Hallo Technix,

 

super Beiträge, vielen Dank, ich habe einiges neues daraus gelernt (Git, Gerrit, Amazon EC2, Robert C. Martin Clean Code) !

 

Einer sehr exzessiven Zerlegung der Funktionalität in viele sehr kleine Module stehe ich persönlich sehr kritsch gegenüber.

Das wird m.E. sonst genauso unübersichtlich wie ein monolithischer Code-Block mit 5000 LOC (Lines of Code).

 

Ich bin halt noch "einer vom alten Eisen".

Vor ca. 20 Jahren (und leider auch bis in die heutige Zeit) war es mein tägliches Brot als (externer) Softwareentwickler, dass ich nur allzufoft in fremden Code-Blöcken mit z.B. 5000 LOC ein Reengineering durchführen musste. Und da kenne ich bis jetzt noch kein besseres Instrument, als Nassi-Shneiderman-Diagramme zu pinseln, um sich da einen Durchblick zu verschaffen.

 

UML-Diagramme dienen, zumindest nach meinen Erfahrungen, wenn sie denn überhaupt eingesetzt werden, lediglich in der Startphase von Projekten zur Koordination des Projektteams, und werden dann aus den verschiedensten Gründen i.d.R. nicht mehr weiter gepflegt.

 

Bei einem gesunden Mittelmaß, also weder allzu extrem zerlegten, kleinen Modulen, aber auch nicht überlangem, sondern überschaubar strukturiertem Code, sind m.E. weder Flußdiagramme noch Struktogramme notwendig, höchstens ein Funktionsbaum um die Aufruf-Abhängigkeiten der einzelnen Module zu dokumentieren.

 

(insbesondere bzgl. der Programmierung im Kleinen, worauf sich Nassi-Shneiderman-Diagramme ja ausschließlich beziehen)

Man kann Nassi-Shiederman-Diagramme auf allen Ebenen einsetzen, nicht nur in der Programmierung im Kleinen !

 

Ganz im Gegenteil: Nassis sind doch nichts weiter als Pseudocode der in eine Grafik gezwängt ist, und Pseudocode kann man völlig ohne Grafik auf jedem beliebigen Abstraktionslevel - der ebenso rein fachlicher Art sein kann - schreiben und im Top-Down-Vorgehen bis zu einer Ebene herunterbrechen, ab der man es als sinnvoll erachtet, überhaupt erst mit dem Programmieren zu beginnen.

 

Verstehe bitte meinen Beitrag keineswegs als Kritik, sondern als Gedankenaustausch unter Softwareentwicklern, das ist halt meine Sicht !

Ich habe mich gefreut, daß Du Deine Sicht der strukturierten Herangehensweise so detailliert vorgestellt hast.

 

Schönen Gruß, Der Wolf

Ich hatte die Beiträge im Umfeld des Community-EA positioniert, weil ich dachte, daß die Dinge dort Software-Projekt-mäßig bisher noch nicht auf der best-möglichen Schiene laufen. Die Abtrennung ist gut, wenn das inhaltlich Nutzbare daraus auch dorthin übernommen wird.

 

Das mit der sehr exzessiven Zerlegung der Funktionalität in viele sehr kleine Module sieht wirklich oft noch viel unübersichtlicher aus als ein vielzeiliger monolithischer Code-Block. Das hatte ich auch schon vorab zugegeben.

 

Trotzdem ist die maximale Zerlegung nach dem derzeitig aktuellem Wissen der Software-Technologie berechtigt der state-of-the-art und stellt gerade für die modernen hoch-produktiven agilen und Test-basierten Arbeitsweisen eine notwendige Grundlage dar (ohne etwa darauf beschränkt zu sein). Damit wird insbesondere das Erstellen von zusätzlichem Code für Unit-Tests wesentlich vereinfacht, wobei ausreichender Test-Code in aller Regel ähnliche oder noch größere Ausmaße hat wie die zu testende Software selber.

 

Module müssen so einfach sein, daß im Test eine 100 %-ige lokale Pfad-Abdeckung innerhalb des Moduls erreicht wird. Das ist in großen Monolithen mit vielen Fall-Unterscheidungen wegen der kombinatorischen Explosion der alternativen Pfade nicht mehr möglich. Ungetestete Pfade sind aber noch schlechter als gar nicht erst geschriebene Pfade, zumindest auf Ebene der kleinsten testbaren Einheiten.

 

Eine weitere ganz wichtige moderne Arbeitsweise ist andauerndes und unaufgefordertes Refactoring, was bedeutet, daß der Code von jedem qualifiziertem Leser bei Verbesserungs-Möglichkeiten auch umgehend verbessert wird, auch in kleinen Dingen, wie z. B. schlecht gewählten Bezeichnern.

 

Das ist bei Code, den man lokal nicht mit einem Blick übersehen kann, aber kaum möglich. Ebenso wird niemand Verantwortungs-bewußt Code ändern, der nicht durch umfassende Unit-Tests abgedeckt ist, weil er damit das gesamte Software-System beschädigen kann.

 

Beim Navigieren wird bei der sehr starken Zerlegung meist unterschieden zwischen den ohne Weiteres im Quelltext übersehbaren kleinen Modulen und größeren Paketen/dem System im Ganzen. Da sind leistungsfähige Entwicklungs-Umgebungen mit vernünftigen grafischen Browsern gefragt.

 

Wenn man die nur sehr eingeschränkt hat, wie z. B. innerhalb des MetaTraders, kann man sich mit gut gewählten Sub-Systemen in eigenen Verzeichnis-Strukturen, Bezeichner-Konventionen und Dokumentations-Kommentaren und einem Dokumentations-Tool helfen ... und den verbleibenden Rest mit der Hand malen, z. B. mit Visio oder Dia etc.

 

Bei so katastrophal geschriebenen Alt-Last-Code-Blöcken, wie 'Der Wolf' sie angibt, sind Nassi-Shneiderman-Diagramme wirklich ein gutes Hilfs-Mittel. So ein Code sollte heute aber von niemandem mehr geschrieben werden, weil er nach Jahrzehnte-lang theoretisch gesichertem und vielfach in Projekten belegtem Erkenntnis-Stand der Software-Branche bekannt ist als teuer in der Wartung, demotivierend für die Entwickler, anfällig für alle Arten von Fehlern und hemmend für Neu-Entwicklungen, sowohl im Kontext der vorhandenen Software als auch beim Übergang auf eine völlig neue Version.

 

Da die Probleme neben den objektiven Mängeln der Code-Verständlichkeit noch zusätzlich durch offenen oder latenten Ekel vor hirnrissigem Code bei den damit beschäftigten Entwicklern um ganze Größen-Ordnungen verstärkt werden, ist so ein Stil heute für Neu-Entwicklungen ein absolutes Tabu, wenn man seine Entwickler nicht absichtlich frühzeitig zum Burn-out hetzen will.

 

Selbst kleinste If-Anweisungen können mit einem semantisch bedeutsamen Namen als Einzeiler-Funktion geschrieben werden. Das mag zwar nach Super-Overhead aussehen, hat aber den Vorteil, daß jeder auch ohne Kommentar sofort weiß, was der Autor da prüfen wollte. Als Neben-Effekt wird gleich noch eine semantische Prüfung mit dem Bezeichner geliefert. Macht dieser fachlich Sinn und ergibt ein normales Wort, wo prüft man vermutlich was Wesentliches. Fällt er eher als Aneinanderreihung vor Worten aus oder hört sich sonstwie krank an, so ist möglicherweise die Prüfung selber fragwürdig.

 

Über Laufzeit-Verlangsamungen durch gut lesbaren Code braucht man heute in den meisten Fällen nicht wirklich nachzudenken, da gibt es viele andere Faktoren, die mehr kosten. Insbesondere kann eine falsche Komplexitäts-Klasse eines Algorithmus bei nur genug zu verarbeitenden Daten nicht durch irgendwelche Optimierungen an Implementierungs-Details ausgeglichen werden.

 

Bei Compiler-Sprachen gilt: Jeder Code braucht nur einmal vom Computer gelsesen zu werden, aber meist viel öfter von Menschen. Daher ist alles, was dem Menschen die Arbeit erleichtert gut, richtig und wichtig.

 

Zum ganzen Komplex des Clean Code war das empfohlene Buch Clean Code schon eine ziemlich brauchbare Quelle und ich will hier nicht das ganze Buch wiedergeben, zumal ich es im Moment nicht vor mir liegen habe.

 

Wenn man UML-Diagramme nur am Anfang nutzt, ist man nicht sehr produktiv. In einer vernünftigen Werkzeug-Umgebung sind Zwei-Wege-Tools Pflicht, die Änderungen sowohl in Richtung UML -> Code als auch in Richtung Code -> UML propagieren.

 

UML-Diagramme werden bei professionellen Tools auch nicht Stunden-lang für irgendeine Doku-Ablage schön-formatiert, sondern ad-hoc im Moment der Frage mit den entsprechenden Filtern aufgestellt und von dort wird unmittelbar in den Quelltext weiter geklickt.

 

Das "gesunde Mittelmaß" gibt es bei Clean Code gerade nicht, weil es da überhaupt kein Mittelmaß gibt. Entweder ist etwas state-of-the-art oder muß sofort und ohne irgendwelche Rückfragen geändert werden, weil es dann eben auch nicht "gesund" war. Clean Code setzt nicht auf irgendwelche Bürokratien und kleinteilige Arbeits-Aufträge sondern auf die Kompetenz aller Beteiligten inkl. des Bewußtseins damit langfristig die Kosten für die Wartung um eine Größen-Ordnung zu reduzieren, indem kaum mehr teure ad-hoc-Reparaturen fällig sind oder der Code zu "verwesen" beginnt, weil sich niemand mehr um ihn kümmert, weil er zu eklig ist ("stinkt").

 

Zur Beschreibung potentieller Nutzungs-Möglichkeiten, wie sie von Objekten ja erst einmal mit nur geringem erforderlichem Kontext bereit gestellt werden sollten, sind Nassi-Shneiderman-Diagramme nicht geeignet. Sie können nur bereits vorgedachte Abläufe aufzeigen.

 

Programmierung im Großen hat nicht nur mit der aktuell genutzten Aufruf-Hierarchie zu tun, sondern auch immer mit potentiellen Möglichkeiten, wo bereits fertige Objekte in neue, noch unbekannte Zusammenhänge gebracht werden.

 

Immer wenn das nicht geht, sind die Objekte zu wenig universell angelegt und die Software hat einen Entwurfs-Schaden. Wenn dann die Modul-Struktur so abgeändert wird, daß allgemeiner nutzbare Teile von den eher sehr spezifischen abgetrennt werden, entstehen zwangsläufig feingranulare Objekt-Strukturen mit teils nur wenig neu hinzu gekommener Funktionalität von schon vorhandenem zu neu hinzugefügtem, die Anfänger in großen Klassen-Hierarchien meist sehr verwirren, die sich oft fragen, warum solche Unmengen kaum voneinander unterschiedlicher Klassen eingeführt werden.

 

Die Beschreibung von Programm-Systemen im Großen ist nicht an Pseudo-Code als dem "Wie geht es?" interessiert, sondern an der Präsentation der potentiellen Möglichkeiten der Objekte, dem "Was geht damit?". Bei ordentlicher Bezeichnung sagt alleine der Name des Objektes für einen mit dem Anwendungs-Gebiet Vertrauten genug aus, um das Objekt und seine Methoden einsetzen zu können.

 

Irgendwelche unerwarteten, über die Intention des gut gewählten Bezeichners hinaus gehende Dinge sind streng verboten ("Prinzip der geringsten Überrraschung", die Funktion "Tür_Öffnen" darf eben auf keiner Hierarchie-Stufe egal wie tief verborgen jemals die Funktion "Bombe_Zünden" aufrufen, es sei denn wir implementierten gerade die Klasse "Tür_mit_Sprengfalle" [die übrigens gerade darum besser mittels Interface oder Mixin gebaut würde]).

 

Alleine schon das reine Aufzählen aller vorhandenen Objekte und ihrer Funktionalitäten nur mit ihren Bezeichnern ist bei gängigen Klassen-Bibliotheken wie in .NET, Java odr Python bei Tausenden von Objekt-Klassen und Zehntausenden Methoden nicht mehr trivial. Um diese Präsentation geht es bei der Programmierung im Großen.

Ganz brachial überspitzt, soll demnach eine Funktion nur in etwa so komplex sein:

function top_function(args)
 if condition(args)
   then return sub_function_for_case_true(args)
   else return sub_function_for_case_false(args)

In dem Buch sind sehr viele gute und eher zu vermeidende Pattern zusammengefaßt.

 

In einem Lehrbuchkkontext sind solche Prämissen sicher interessante und provokante Thesen - in der Praxis jedoch wenig zielführend. Ich halte die Modularisierung nach generellen (Wiederverwertbaren) Modulen und programmspezifischen Modulen für sehr sinnvoll - eine gute, durchdachte Namingconvention von Variablen und Funktionen für unerlässlich. Für Module hat sich die Daumenregel - nicht länger als eine Bildschirmseite ganz gut bewährt - allerdings halte ich nichts von kryptischen code um möglichst kurze Routinen zu schreiben - lieber länger und dafür "ineffizienter" (sofern nicht zeitkritische Routinen) aber von Jedermann leicht lesbar.

Wingman beipflichtend ergänzend : clevere Namen für Variablen und eine Seite für wirklich neuen Quelltext . Teilweise haben meine #Include mehrere Seiten, dann ist aber der Inhalt widerholend & unverändert . Zum Beispiel durchsuche ich verschiedene Array auf eine Weise , will diese Array´s gut & verständlich benennen . Aber ich habe keinen Algoythmus dafür gefunden, wie ich den Namen des Array selber variabel gestalten kann . ( Min1[][] , Min5[][]....). Dann dupliziere ich einfach die CodeSequenz .

 

Will sagen : Eine Seite oder aber ein in sich geschlossenes Thema .

 

Lobo

 

PS.: @ Technix , danke :-)