Großer Programme wartbar halten
-
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.