PureBaser hat geschrieben:Was mich interessiert, ist die Teamfähigkeit: Ich hab schon
einige Programmentwürfe. Das größte geplante (kommerzielle)
Programm wird fast doppelt sogroß sein wie japBe, aber mit
etlichen PlugIns, einigen Datenbanken, und Tools, so dass ich
mit mehreren Personen arbeiten möchte.
Wie hast Du denn bei der Projektplanung errechnet, dass das
Programm "fast doppelt so groß sein wird wie jaPBe" ?
Meinst Du damit die Größe des Quelltextes, oder die resultierende
EXE/DLL-Größe des Programmes + Plugins bei PB 4.0 ?
PureBaser hat geschrieben:Wie stelle ich das am besten an - geht das überhaupt trotz
fehlen von OOP?
Natürlich geht das. OOP macht es durch die Konzepte der Kapselung
nur leichter.
Du kannst auch mehrere Leute mit ASM-Kenntnissen nehmen,
die alle zum programmieren Notepad verwenden.
Geänderte Sourcen werden dann per eMail an alle Mitglieder
geschickt.
Es gibt immer einen einfachen und einen schweren Weg.
Viele Leute wählen den einfachen Weg und nehmen entspr.
Hilfswerkzeuge um die Sache etwas zu erleichtern.
Zur Codeverwaltung für Teams solltest Du Dir mal
SubVersion
oder das alte
CVS anschauen.
(evtl. noch
WinCVS und
TortoiseCVS, falls Du auf Win arbeitest)
Das sind Versionkontrollsysteme auf die, wenn gewünscht,
mehrere User gleichzeitig zugreifen können.
Gleichzeitig werden damit alle Änderungen am Source verwaltet.
So hat man eine gute Übersicht und Dokumentation der Änderungen
im Source. Bei Bedarf kann man auch zu alten Versionen eines
Codes wieder zurückgehen oder versch. Versionen eines Codes
miteinander vergleichen uvm.
Das sind aber nur Tools die Dir das alles erleichtern. Um einen
Programmierstandard für das Team und gute Dokumentation
mußt Du Dich selbst bemühen.
D.h. es sollte Regeln geben an die sich alle Coder im Team
sehr genau halten. Es soll ja nicht jeder im Source "rumpfuschen"
können wie er will.
Codes müssen sauber und einheitlich formatiert geschrieben
werden, so daß auch jedes andere Teammitglied sofort damit
zurecht kommt. Wer Codes schreibt die für andere Personen
schlecht lesbar ist, der ist da nicht so geeignet.
Wichtig ist auch die Dokumentation im Code. Sehr wichtig.
Über jeder Prozedur sollte ein Kommentar/Header sein
in dem der Author drin steht und was genau die Prozedur
macht.
Bei jeder Änderung muß der Ändernde seinen Namen an
den Header anhängen und genau hinschreiben *was* er
*warum* geändert hat.
Alle Einträge natürlich mit Datum.
In den Programmierstandard fürs Team sollten Dinge wie die
Formatierung rein, wie man Funktionen und Variablen benennt uvm.
Da gehört schon einiges dazu. Eine gute Hilfe für den Anfang
kann das Buch
Programmierrichtlinien in der Praxis sein.
Einige Sachen wirst Du aber erst selbst in der Praxis erleben
müßen, um dann aus diesen Fehlern zu lernen.
Da Du es nicht eilig hast, kannst Du nun in Ruhe dieses Buch
lesen und eine komplette Programmierrichtlinie für Dein
Projekt erstellen.
Du kannst Dich in aller Ruhe mit SubVersion anfreunden
und solltest am besten schonmal ein kleineres Projekt
komplett damit verwalten.
Als Projektleiter (nehme ich mal an) mußt Du diese Tools
beherrschen und solltest neuen Team-Mitgliedern am Anfang
ohne Probleme helfen können.
Und da wären wir auch schon beim menschlichen Faktor:
Probleme/Streitigkeiten/Meinungsverschiedenheiten im
Team solltest Du als Leiter schlichten können, denn sowas
kann immer mal vorkommen.
Ein "Es wird so gemacht wie ich es will, basta!" hilft in einem
Team natürlich nicht. Das Team muß ständig miteinander
kommunizieren können.
Von daher ist auch ein IRC-Channel (Chat-Kanal) ganz gut,
da sich dort immer alle Mitglieder absprechen können und
ständig in Kontakt sind. Das austauschen per eMail oder
einer Mailingliste ist da einfach zu langsam und evtl. bekommt
nicht jedes Mitglied alles mit (wenn sich 2 per eMail unterhalten).
Täglich eine LOG-Datei aus dem Chat auf den CVS zu schmeissen
ist auch nicht schlecht, so verpasst niemand eine Besprechung
über das Projekt, auch wenn er mal offline ist.
Die Kommunikation(s-Möglichkeiten) im Team halte ich selbst
aus eigener Erfahrung mit für das Wichtigste überhaupt.
Wenn das nicht stimmt, dann geht es nicht lange gut...
...ist also eine Grundvoraussetzung.
Wenn jemand in der Nacht 2:53 Uhr am Projekt arbeiten will,
dann muß er immer alle aktuellen Informationen und Sourcen
zur Verfügung haben. Wenn man da immer 3 Tage auf eine
Antwort vom Leiter warten muß, wird man wahrscheinlich
schon recht schnell genervt aufgeben.
