Solatic - Projektplanung

[Jesus_666]

Der Grösste vorteil am CVS mit vielen leuten ist aber das mehr Coder mehr sehn , fehler werden effektiver und besser behoben zwar kann das im gegenzug auch zu fehler führen jedoch in einem Gutem Team wird dieses Problem ehr klein sein.

...

Berücksichtige, daß der Kommunikationsaufwand quadratisch wächst, wenn die Teilnehmerzahl linear ansteigt. Ergo verdoppelt sich mit jedem zusätzlichen Coder der Kommunikationsaufwand.

Ein CMS (CVS ist etwas ganz anderes) kann man mit ein, vielleicht zwei Leuten schreiben und es wäre tatsächlich gut, wenn eine Person sich hinsetzt, das Ganze durchplant und umsetzt. Es kann jemand mithelfen, aber Design by committee ist eine sehr schlechte Sache. Der Entwurf sollte von einer Person mit einem klaren Konzept gemacht werden.

BTW, Modularität gleicht nicht unbedingt Wartbarkeit. Als Beispiel führe ich WBB und phpBB an: Letzteres ist modularer als ersteres, aber ersteres ist einfacher zu modifizieren, weil man den relevanten Code nicht aus einem halben Dutzend Includes zusammensuchen muß. Das CMS sollte da modular sein, wo es Sinn macht und da nicht, wo ein monolithisches Design keine nennenswerten Nachteile hätte.

Außerdem kann nicht jeder beliebige Coder unbekannten Code warten, der zeilenweise dokumentiert ist - wenn du wirklich vorhast, daß hinterher ein beliebiger PHP-Coder die Seite warten kann, dann solltest du eine komplette Dokumentation anfertigen, also Zeilenkommentare, ein Designdokument, das darlegt, was warum wie gemacht wurde, eine Spezifikation aller verwendeten Schnittstellen etc. Ein paar Kommentare im Quelltext machen die verwendeten Algorithmen und Ansätze nicht ersichtlich - und speziell die sind es, die man verstehen muß, um eine Software warten zu können.*
Es wäre also erheblich besser, wenn derjenige, der sich für die Konstruktion des CMS verantwortlich zeigt, auch die Wartung übernimmt.



* Einfach nur Kommentare in den Quelltext zu setzen ist kein guter Dokumentationsstil, ehrlich. Damit deckt man nur einen Teil dessen ab, was es über den Code zu sagen gibt - das, was man gerade mit diesem Teil des Codes macht. Dinge wie Algorithmen, Konzepte und Designentscheidungen müssen separat dokumentiert werden, weil sonst hinterher keiner nachvollziehen kann, wie die Software tut, was sie tut und warum sie es tut. An meiner Uni zählen Kommentare im Quelltext für etwa ein Drittel bis die Hälfte der Dokumenatationsnote, weil der externe Text eben immens wichtig ist. Was eine Zeile tut kann man leichter erschließen als weshalb sie verbaut ist.