natürlich hast Du Recht, dass man auch in C++ gute Systeme bauen kann. Das ist ja auch geschehen, schließlich gibt es sehr viele erfolgreiche Systemem mit C++ vor allem im technischen Umfeld.

Meine Erfahrung ist aber auch, dass die meisten C++ Systeme im C/S- oder Webumfeld, die ich bisher gesehen habe, genau nicht klein modularisiert und entkoppelt waren. Und dass dann zu zerlegen ist ein (technischer und wirtschaftlicher) Albtraum. Und die Werkzeugunterstützung ist für Systeme >500 Klassen eine schlichte Katastrophe.

Ich glaube aber auch, dass es dafür viele sprach-inherente Gründe gibt, wie Redundanz in den Headerfiles, das Typsystem und viele goldene Henkel, die eine Automatisierung derart erschweren, dass Refactoring extrem schwierig wird. Dazu kommt noch, dass das verbreitetste Werkzeug Visual Studio keinen vollständigen AST aller Klassen eines Workspaces hält, sondern eher eine klassische Compiler-Linker-Toolkette ist mit ein paar GUI-Gimmicks vorne dran (Visual Studio für .NET ist da deutlich besser implementiert!).

Alles in allem eine sehr frustrierende Angelegenheit, insbesondere wenn man sich anschaut, was Werkzeuge wie Eclipse oder TogetherJ da seit fast zehn Jahren vormachen. Und noch dazu bei der Produktivität der Entwickler ein Desaster (für die Manager unter den Bloglesern

Also mal zu c++: c++ ist meiner meinung nach die einzige portable high-level sprache di ohne vom auskommt. c# ist microsoft spezifisch, objective-c apple, java ist eigentlich schon eine eigene plattform (es gibt ja sogar schon den java desktop). ausserdem kann man in c++ highlevel konstrukte (objekte, reference counting, abstrahierte io, funktionale paradigmen, operator overloading etc.) fast ohne runtime penalty machen.

zur kompilation: ja, du musst natürlich kleine bausteine bilden, aber nicht unbedingt um bilbiothejen zu bauen, sondern um das kompilat (*.o) zu cachen, und parallel zu kompilieren. komplett rekompilieren sollte man eh selten, und ausserdem sollte irgendwo im team ein schneller kompilationsrechner stehen, den man per distcc ansteuern kann. wenn das alles gegeben ist glaube ich kaum, dass du oft kompilationszeiten von mehr als ein paar minuten hast.

und: ja, es gibt viele wege etwas zu machen. man muss sich schon selbst überlegen, welches tool das beste für ein bestimmtes problem ist, aber es gibt auch ne menge bücher die man lesen kann. ausserdem gibt es die stl und boost, die viele standardlösungen vorschlagen.

was refactoring angeht: da fehlt sicher was (gibt es da nix kommerzielles? strange…). aber: man kann sowas ähnliches heute schohn mit gccxml machen, und bald auch mit clang (clang.llvm.org).

Gruss

Genau das möchten doch die agilen Methoden ändern - wenige (aber wichtige) Regeln, ansonsten Fokus auf die Beteilligten und damit Fokus auf das Beleben.

Auch das ist aber kein Ersatz für größere Release- oder Projekt-Retrospektiven, sondern “nur” eine (wertvolle) Ergänzung.