Großer Programme wartbar halten

[watersepp]

Wie kann man ein großes Programm (z.B. Excel) so entwickeln, dass man nicht irgendwann an eine Stelle kommt bei der eine Änderung sich auf viele Teile auswirkt und man nicht mehr viel neues bauen kann ohne das alte kaputt zu machen. Oder kommt man bei einer bestimmten Programmgröße irgendwann immer an so eine Stelle?

[Pito Wilson]

es werden einfach keine änderungen gemacht, die du ganze bisherige struktur über'n haufen werfen würde. so einfach ist das.

[Pito again..]

Pito Wilson schrieb:

du

das sollte ein 'die' sein.

[ad7mac]

Kein Programm kann beliebig weitgehend und beliebig oft erweitert werden.
Es ist nämlich unmöglich, alle möglichen zukünftigen Anforderungen bei der Planung vorherzusehen.

Deshalb ist es wichtig, am Anfang ein Pflichtenheft zu schreiben, das eingehalten wird.

Man kann aber die Wartbarkeit (als Designziel) eines Programms optimieren:

* Planung
* Planung
* Planung
* Programmierung von Prototypen in rapid-prototyping-Sprachen. Erst wenn absehbar ist, daß alles funktioniert, Sprachen mit static typing einsetzen.
* Modularisierung
* Objektorientierung
* Angemessene Dokumentierung
* usw

[Badestrand]

Man kann immer versuchen, seine Programme in relativ unabhängige Module zu unterteilen. Klappt nicht immer, aber meist kann man ein Programm in mehrere "Aufgabenfelder" unterteilen, und die sollten eine möglichst kleine Schnittstelle besitzen. Da gilt dann: Schnittstellen möglichst flexibel halten, damit sie im Nachhinein nicht mehr geändert werden müssen. Wenn du nur hier und da die Implementation ändern musst, droht meiner Meinung nach nicht viel Gefahr für das Gesamtprojekt

edit: Das ist natürlich nur meine Ansicht, kann nirgendwo nachgelesen werden und beruht auf subjektiver Erfahrung.

[thordk]

planung, planung und noch mehr planung. für projekte dieser größenordnung wäre es nicht ungewöhnlich, mehrere monate in reine designplaung zu investieren, ohne auch nur eine einzige zeile code zu produzieren.

[asdfgh]

Nicht C++ benutzen.
Ab einer gewissen Größe sind C++ Projekte nur noch grauenhaft.

[guenni81]

Das wichtigste um ein umfangreicheres Projekt wartbar zu halten ist wie schon erwähnt die Planung. Das beste (aus meiner Sicht) ist das Projekt in kleine Teile zu unterteilen und flexibel zu halten.

@asdfgh
Das hat nix mit der Programmiersprache zu tun, sondern mit dem Projekt Aufbau.

[asdfghj]

guenni81 schrieb:

@asdfgh
Das hat nix mit der Programmiersprache zu tun, sondern mit dem Projekt Aufbau.

Es hat AUCH mit der Programmiersprache zu tun. Neue Sprachen wie Java und C# machen die Verwaltung großer Projekte definitiv einfacher.

[Badestrand]

asdfghj schrieb:

Es hat AUCH mit der Programmiersprache zu tun. Neue Sprachen wie Java und C# machen die Verwaltung großer Projekte definitiv einfacher.

Und wie? Der einzige grobe Unterschied, was mir einfällt, wäre die Zusammenpappung von Deklaration und Implementation, was ich nicht unbedingt unter vereinfachter Verwaltung verstehe.. Also meine Eingangsfrage ist ernst gemeint, bin gespannt

[rüdiger]

geht doch einfach nicht auf solche Trollereien ein. Provozierendes Statement und keine Argumente == Trollerei. Muss ja nicht wieder ein sinnloser 30 Seiten Flamewar werden. (Falls doch, lösch ich einfach alles was in die Richtung geht!)

[adf]

Die Argumente wären dir klar, wenn du schon mal an einem größeren Projekt gearbeitet hättest.
Nur ein paar Stichpunkte: Die Aufteilung in Header und Cpp Dateien macht Probleme. Man muss ständig hin und herspringen und verliert leicht den Überblick bzgl. Header-Includes und Forward Deklartionen.
ALLE C++ IDEs bieten im Vergleich zu Java und C# armselige Refactoring Möglichkeiten. Da ich nun mal eine IDE nehmen muss, ist es auch ein praktisches Problem der Sprache.
C++ hilft nicht Dateien physisch zu strukturieren (Packages).
C++ ist komplexer, was sich vor allem bei großen Programmen negativ auswirkt. Fehlerbehandlung ist in C++ auch nicht so konsequent wie in neueren Sprachen (wo ich z.B. Exception-Handling einbauen MUSS).
Und dann es da noch viele Details wie eine mickrige Lib, #defines usw usw.

[anmerkung]

Bevor die C++ Fans wieder ausflippen: Ich sage nicht das C++ schlecht ist. Ich mag die Sprache und benutze sie selber gerne. Allerdings sehe ich die Dinge wie sie nun mal in der realen Arbeitswelt sind, und da sind große Projekte (> 10.000 Klassen) in C++ nun mal schwieriger zu Handhaben als z.B. in Java oder C#.

[Badestrand]

Das ist wohl wahr, mit >10k Klassen hab ich noch nie gearbeitet (will ich auch nicht ).
Gebe dir in einigen Punkten recht:
- defines können schwierig sein
- Includes und Forward-Deklarationen können ungeheuer nervig sein
- Fehlerbehandlung ist wirklich inkonsequent, obwohl man das imho leicht durch Coding-Conventions regulieren kann

Wo ich nicht mit dir übereinstimme:

> C++ hilft nicht Dateien physisch zu strukturieren (Packages)
Das ist wohl war, lässt sich aber durch physische Unterordner und namespaces selbst leicht bewerkstelligen

Die Aufteilung in Header und Cpp Dateien macht Probleme.
Gerade die Aufteilung sehe ich als großen Vorteil! In Java-Klassen kann man gut und gerne mal 50 Zeilen überspringen, um zu der nächsten Funktionsdeklaration zu gelangen - nicht gerade übersichtlich. Außerdem kann in einer .cpp etwas geändert werden, ohne dass der Rest vom Programm davon beeinflusst wird.

An Libs sehe ich übrigens nur Vorteile, sauberes Implementation-Hiding, und mit der Const-Correctness hat man mit C++ eine große potentielle Fehlerquelle weniger als in Java/C#.

Nichtsdestotrotz kann und will ich nicht darüber urteilen, welche Sprache denn nun schlecht/gut/am ehesten für große Projekte geeignet ist. Wollte ja nur wissen, was denn die Argumente für Java/C# sind, danke für die Aufzählung!

[kilo]

Also bei so großen Projekten ist die Sprache nicht das große Problem. Da kommt es schon hauptsächlich auf das Design an. Wenn das irgendwann mal für die gewünschen Erweiterungen nicht mehr ausreicht, dann ist es egal ob das mit Java oder C++ umgebaut werden muss, weil dann diese einfachen Refactoringmethoden bei weitem nicht ausreichen.

Klar hat Java z.B. schöneres Exceptionhandling und mit dem Stacktrace ist es auch einfacher einen Fehler zu fixen, aber wenn man so ein großes Projekt hat, dann sollte man sauber programmieren und vorher überlegen und es nicht erst zu solchen Fehlern kommen lassen. In C++ überlegt man genauer ob was NULL sein kann oder nicht , als bei Java (meine Beobachtung).

[Marc++us]

thordk schrieb:

planung, planung und noch mehr planung. für projekte dieser größenordnung wäre es nicht ungewöhnlich, mehrere monate in reine designplaung zu investieren, ohne auch nur eine einzige zeile code zu produzieren.

Trotzdem erhöht eine Mehrleistung der Anfangsplanung nicht zwangsläufig den Enderfolg. Das liegt daran, daß während der Dauer der Planungsphase bereits die am Anfang festgestellten Anforderungen "wandern".

Man kann sich das Problem visuell vorstellen:

Die realen Anforderungen sind eine (ziemlich verrauschte) Kurve. Planung beruht nun darauf, daß man zu einem Zeitpunkt t sich die Funktion und die Vergangenheit anschaut, und ab dort dann extrapoliert. Das bedeutet aber auch, daß die Differenz zwischen extrapolierter Planung und realer Kurve rasch driften kann.

Problematisch ist ebenfalls, daß bei vielen Projekten gewisse Benutzergruppen zu Beginn der Planung noch nicht zur Verfügung stehen, so daß man sich bereits dabei auf Abschätzungen der Interviewpartner verlassen muß.

Folglich ist ein früher Rollout von Betas essentiell, um überhaupt schnell Abweichungen fangen zu können.

Wenn man sich fragt, was die Kundenanforderungen mit Wartung zu tun haben, dann muß man sagen "fast alles". Denn letztlich sind diese Anforderungen eigentlich meistens der Grund, warum man überhaupt wartet. Die Vermeidung von Wartung ist also keine grundsätzlich schlechte Idee.

Weiterhin würde ich auf die Frage noch eine weitere Antwort geben wollen: "man schreibt keine große Programme".

Das bedeutet einfach, daß man sich eben nicht durch die Stilmittel der Programmiersprachen darüber täuschen lassen sollte, daß große Programme einfach problematisch sind - nach einiger Zeit.

Systemarchitekturen, die aus getrennten (und das meine ich sehr wörtlich) Modulen bestehen, die über einen "Software-Datenbus" miteinander verbunden sind oder auf einer gemeinsamen Datenbank arbeiten sehe ich daher als besseres Mittel um eine Struktur wartbar zu halten. Das kann zum Beispiel so aussehen, daß bestimmte Anwendungsfälle oder Applikationen für bestimmte Anwendergruppen komplett in eine eigene Applikation ausgelagert werden. Änderungen bleiben daher lokal begrenzt.

Natürlich leidet oft die Performance unter solchen Ansätzen. Irgendeinen Tod muß man sterben.

[nep]

Das was du am Schluss nennst, ist doch gerade das wo zur Zeit der große Trend hingeht, alles eben möglichst service-orientiert zu halten. Da trifft dein Satz ja auch voll und ganz zu "man schreibt keine großen Programme", und das hängt ganz sicher nicht von der verwendeten Prog.Sprache ab, wie manche hier ja vermuten...

[naja]

Marc++us schrieb:

Systemarchitekturen, die aus getrennten (und das meine ich sehr wörtlich) Modulen bestehen, die über einen "Software-Datenbus" miteinander verbunden sind oder auf einer gemeinsamen Datenbank arbeiten sehe ich daher als besseres Mittel um eine Struktur wartbar zu halten. Das kann zum Beispiel so aussehen, daß bestimmte Anwendungsfälle oder Applikationen für bestimmte Anwendergruppen komplett in eine eigene Applikation ausgelagert werden. Änderungen bleiben daher lokal begrenzt.

Irgendwann gibts aber auch da Probleme. Wenn man mal mehr Daten braucht als die Schnittstelle hergibt, dann kann man die Schnittstelle erweitern und alles anpassen, was diese benutzt oder man macht eine zweite Schnittstelle die fast das gleiche macht nur mit zusätzlichen Daten. Siehe WinAPI die ganzen ...Ex Funktionen oder im SAP System ...2. Ist auch nicht mehr wirklich schön.

[thordk]

dass große c++ projekte sehr schnell schlechter wartbar werden, als beispielsweise java, muss ich zustimmen. das ganze ist schlicht in der natur von c++ begründet. viele entwickler, viele paradigmen und keine fixen best practices sorgen in c++ viel schneller dafür, dass strukturen unübersichtlich werden.

es ist in der praxis schlicht so, dass viele unterschiedliche entwickler, mit unterschiedlichen hintergründen, an demselben projekt arbeiten. da treffen die c-jünger der mitt-80er auf die objektorientierten spossel der 90er und schon wird ein projekt ein einziges kraut und rüben werk.

[also]

für sowas gibts codeconventions und man könnte codereviews vor dem einchecken machen...

[thordk]

also schrieb:

für sowas gibts codeconventions und man könnte codereviews vor dem einchecken machen...

du hast noch nicht viel praxiserfahrung gesammelt oder?