Großer Programme wartbar halten
-
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
-
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!)
-
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.
-
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#.
-
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 kannWo 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 bewerkstelligenDie 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!
-
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).
-
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.
-
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...
-
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.
-
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.
-
für sowas gibts codeconventions und man könnte codereviews vor dem einchecken machen...
-
also schrieb:
für sowas gibts codeconventions und man könnte codereviews vor dem einchecken machen...
du hast noch nicht viel praxiserfahrung gesammelt oder?
-
warum?
-
Weil sich meist keiner dran hält und sich jeder selbst für den besten Programmierer hält...
Und genau aus dem Grund habe ich nämlich meine letzte Arbeitsstelle gekündigt, weil es dort ein Projekt mit mehreren tausend Source-Dateien gibt (zwar auf verschiedene DLLs verteilt, aber durch die Header-Dateien dann halt doch wieder verbunden), an dem jeder der ca. 10-15 Entwickler mal hier mal dort den Code ver'schlimm'bessert hat.
-
Th schrieb:
...und sich jeder selbst für den besten Programmierer hält...
das tun nur echte pfeifen.
-
Th schrieb:
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.
-
bagpipe schrieb:
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.