Im Team arbeiten - Wie am besten?

[Unfug]

Hi,

Es geht um folgendes. Wir (das sind 2Leute, die nur über Internet kommunizieren) wollen ein Programm schreiben.
Das Programm wird in Java geschrieben. Jetzt stellt sich , da ich noch nie vorher im Team gearbeitet habe, wie bewerkstelligt man das am besten?

Jeder bekommt ein Package?
Package1: Darstellung
Package2: Funktionen
Package3: ....

Wird das mergen dann nicht kompliziert? Sollte man dann vorher schon die einzelnen Klassen absprechen?

Vielleicht habt ihr ja schon mehr Erfahrung und könnt bisschen aus dem Nähkästchen plaudern.
Danke

[eXistence]

Naja, bzgl. des Software-Designs (welche Klassen und Schnittstellen brauche ich?) sollte man sich schon einig sein.

Beim implementieren selbst sind Tools wie CVS oder Subversion äußerst hilfreich, da so jeder relativ elegant an den Quelltext der anderen rankommt ohne per Hand irgendwelche Dateien rumschieben zu müssen.

[ooAlbert]

wärs nicht am sinnvollsten vorher mit uml einen plan zu erstellen und globale variablen festzulegen, bzw. überhaupt die stilistik? so hätten beide dann erstmal gleiche ausgangspositionen...

[Trap]

Um mal bei den konkreten Sachen anzufangen:
Irgendein Tool benutzen was Sourcecode verwaltet, verschiedene Änderungen an einer Datei die sich nicht widersprechen automatisch anwendet und immer die aktuellste Version jeder Datei hat. Zum Beispiel Subversion.
Das von Hand zu machen ist nervig, fehleranfällig und völlig unnötig.

Nur über Internet ist keine große Einschränkung, wenn man VNC oder sowas ähnliches und irgendein Voice-Chat Programm nimmt ist das bei 2 Leuten fast so gut wie in echt zusammen zu sitzen.

Diese Sachen sollte man ganz am Anfang installieren und sicherstellen, dass sie ordentlich funktionieren und einfach zu benutzen sind, das später einzurechten geht meistens schief, da ist dann nämlich das Programmieren wichtiger.

Zu den abstrakteren Sachen:
Bei der Projektdurchführung gibt es tonnenweise völlig gegensätzliche Empfehlungen. Für kleine Teams ist etwas in Richtung agile software development / extreme Programming gut geeignet.

Kurz gesagt geht es dabei darum: Viel gemeinsam an Code arbeiten, immer ein Feature für den Nutzer nach dem anderen einfügen (ein Feature sollte man in einer überschaubaren Zeit fertig haben höchstens ein paar Tage), dabei möglichst einfache Implementierung wählen (nicht auf Eleganz achten) und nach jedem fertigen Feature gucken ob man den Code sauberer umstrukturieren kann. Beim Feature implementieren keinen Code schreiben, der nicht direkt dazu benutzt wird das Feature zu implementieren.
Mindestens beim Umstrukturieren bietet es sich an es zusammen zu machen, die Features schreiben kann man auch einzeln.

Mit Google findet man noch viel mehr und genaueres.

[darph]

globale variablen
In Java?


Aber prinzipiell stimmt's schon. Ihr solltet euch vielleicht überlegen, welchem Programmierstil ihr folgen wollt. Traditionelles Software-Engineering mit Pflichten- und Lastenheft, Design by Contract? Oder soll das ganze Gedeihen, während es wächst?

Wenn ihr sowas noch nie gemacht habt, wäre es vielleicht sinnvoll, wenn ihr bereits wirklich ein Klassendiagramm erstellt, schaut, welche Methoden ihr braucht und über welche Schnittstellen ihr kommunizieren wollt.


Und dann wäre eine irgendwie geartete Versionsverwaltung nicht schlecht. ;)

[Unfug]

Ok danke. Für die Tips.
Ich denke wir werden vorerst mal ein UML anwenden, damit wir uns einig sind welche Schnittstellen und Attribute existieren.

Wie programmiert man denn am besten, wenn z.B
Package1.Klasse1.getDaten() = gibt String zurück

und ich jetzt an
Package2.Klasse1 arbeite und die Daten von dem oberen brauche.
Dann muss man ja wirklich vorher explizit sagen, welche Methode einen Rückgabewert hat und welche nicht. Freies Programmieren wird dann sicherlich schwer. Auch frag ich mich, wie man denn so vorgehen sollte bei den Packages. Kann ja sein, daß ich meins schon fertig habe, mein Partner seins noch nicht und ich aber aufgrund fehlenden Methoden von ihm, dann auch nicht testen kann ob alles einwandfrei funktioniert.

Gruß

[darph]

Ok danke. Für die Tips.
Ich denke wir werden vorerst mal ein UML anwenden, damit wir uns einig sind welche Schnittstellen und Attribute existieren.

Wie programmiert man denn am besten, wenn z.B
Package1.Klasse1.getDaten() = gibt String zurück

und ich jetzt an
Package2.Klasse1 arbeite und die Daten von dem oberen brauche.
Dann muss man ja wirklich vorher explizit sagen, welche Methode einen Rückgabewert hat und welche nicht. Freies Programmieren wird dann sicherlich schwer. Auch frag ich mich, wie man denn so vorgehen sollte bei den Packages. Kann ja sein, daß ich meins schon fertig habe, mein Partner seins noch nicht und ich aber aufgrund fehlenden Methoden von ihm, dann auch nicht testen kann ob alles einwandfrei funktioniert.

Gruß
Genau das sind die Schnittstellen. (y)

Interfaces definieren.

[RMC]

Ok danke. Für die Tips.
Ich denke wir werden vorerst mal ein UML anwenden, damit wir uns einig sind welche Schnittstellen und Attribute existieren.

Wie programmiert man denn am besten, wenn z.B
Package1.Klasse1.getDaten() = gibt String zurück

und ich jetzt an
Package2.Klasse1 arbeite und die Daten von dem oberen brauche.
Dann muss man ja wirklich vorher explizit sagen, welche Methode einen Rückgabewert hat und welche nicht. Freies Programmieren wird dann sicherlich schwer. Auch frag ich mich, wie man denn so vorgehen sollte bei den Packages. Kann ja sein, daß ich meins schon fertig habe, mein Partner seins noch nicht und ich aber aufgrund fehlenden Methoden von ihm, dann auch nicht testen kann ob alles einwandfrei funktioniert.

Gruß


Naja, es muss halt daweil so abgegrenzt werden, dass die Teile alleine entwickelt werden können. Die Daten, die du von ihm kriegst, kannst du ja derweilen simulieren. Du musst sowieso annehmen, dass es sich um eine Blackbox handelt und du die Daten in dem Format auf dieser Schnittstelle bekommst, die vorher ausgemacht wurden.

Wichtig ist daher vorher zu wissen:

- Wie sieht die Struktur des Programms aus
- Wo sind die wichtigsten Schnittstellen (Welche Daten brauchst du von ihm, welche er von dir - wie sieht dann zB die Funktion dazu aus)
- Wie liegen die Daten vor (Parameter, Liste, File etc.)
- Wie sind diese Daten aufgebaut (wo steht was)

Das muss vorher stehen. Dann geht das schon. Änderungen kommen natürlich dazu, aber man sollte es vorher so gut wie möglich festlegen.

[ethrandil]

Falls du mal an dem Code deines Kollegen was ausbessern willst, wirst du dich freuen, wenn du ihn nicht das erste Mal siehst. Ansonsten ist ja das meiste hier schon gesagt worden. (Gerade wenn du einen Teil seines Codes brauchst um deinen Teil zu testen, wirst du dich freuen wenn du weißt wie du das kurz in seinem Code ergänzt.)

Achja, was bei XP noch dazukäme: (Unit-)Tests.

- eth

[Trap]

Wichtig ist daher vorher zu wissen:

- Wie sieht die Struktur des Programms aus
- Wo sind die wichtigsten Schnittstellen (Welche Daten brauchst du von ihm, welche er von dir - wie sieht dann zB die Funktion dazu aus)
- Wie liegen die Daten vor (Parameter, Liste, File etc.)
- Wie sind diese Daten aufgebaut (wo steht was)

Das muss vorher stehen.
So genau planen kann man nur wenn man ein schon x-mal gelöstes Problem zum x+1ten mal löst. Wenn man etwas programmiert was einem selbst neu ist, dann ist diese Art von Spezifikation durch Planung ziemlich blindes Raten.

Wenn man sich bei der Schnittstellen-Definition nicht auf die Implementierung auf beiden Seiten bezieht kommt oft völliger Unsinn raus, wie z.B. XML-Schnittstellen zur Übergabe der Spieldaten an die Physikengine und zurück ;)