du

das sollte ein 'die' sein.

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

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

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

@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.

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

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!

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).

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.

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.

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.

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

du hast noch nicht viel praxiserfahrung gesammelt oder?

...und sich jeder selbst für den besten Programmierer hält...

das tun nur echte pfeifen.

Weil sich meist keiner dran hält und sich jeder selbst für den besten Programmierer hält...

Nicht mal an die Codeconventions? Bei uns gibts sogar reviews.

Th schrieb:

...und sich jeder selbst für den besten Programmierer hält...

das tun nur echte pfeifen.

So einfach würde ich mir das nicht machen wollen. Du hast hier schließlich genau dieses Phänomen präsentiert - Du hälst Dich für gut, und gewisse andere Leute für Pfeifen.

Es ist in der Softwareentwicklung ein außerordentliches Problem, daß die Masse der Entwickler ihre Vorgehensweise für die einzig richtige hält und nur sehr schwer andere Praktiken adaptiert. Es gibt vermutlich kaum einen anderen Zweig der Technik, der so viele ausgeprägte Individualisten mitschleppt, und gleichzeitig so viele Freiheitsgrade zum Lösungsentwurf bietet.

In der Praxis sind in einem Team immer viele Individualisten anzutreffen, aber nur ein Bruchteil davon ist wirklich sehr gut, in der Mischung sind das real zu lösende Probleme - man hat das Projektteam, das man bekommt, nicht das, welches man sich wünscht.

Große Projekte mit solchen Teams kann man nur stemmen, wenn man das Projekt so untergliedert, daß sich die Individualisten nicht ins Gehege kommen. Die Vorgehensweise, so was durch Regeln und Vorschriften kanalisieren zu wollen, entspricht nicht so ganz der Verhaltensweise der Entwickler. Wenn das in einem Team funktioniert, dann meistens, weil es sehr homogen zusammengesetzt ist. Aber da hätte man die Regeln auch nicht so nötig.