Entwickler-Ecke :: Thema anzeigen - Wie im Team arbeiten?

Xiut - So 17.01.10 16:56
Titel: Wie im Team arbeiten?

Hallo zusammen!

Ich hab folgendes Problem:
Ich bin 15 Jahre alt und beschäftige mich schon recht lange mit Delphi.
Da mein Vater Selbständiger Entwickler ist (von dem hab ich auch gerlernt =) ) und ich ihm in den Ferien und am Wochenende aushelfen möchte, suche ich eine möglichkeit dies so efizient zu tuhn wie es geht.

Nur da ist der Punkt. Wie Entwickelt man am besten Programme in einem Team?
Schreibt dann jeder nur Funktionen und die werden zusammen kopiert oder gibt es Programme mit denen man sozusagen den gleichen Quellcode zusammen ändern kann?
Oder vielleicht auch ganz anders?

Wäre nett wenn ihr mir da ein paar möglichkeiten oder auch Programme die einem dabei helfen nennen könntet =)

Vielen dank!

Tim =)

Moderiert von Narses: Topic aus Sonstiges (Delphi) verschoben am So 17.01.2010 um 23:31

Martok - So 17.01.10 17:22

Generell möchtest du dich auf jeden Fall mit Versionskontrolle beschäftigen.

Außerdem wichtig: Kommunikation (gut, mit deinem Vater reden dürfte noch machbar sein :P ); ansonsten bräuchte man schon sowas wie Bugtracker oder gemeinsam nutzbare Projektverwaltungen.
Der Code sollte möglichst auch nach Standards geschrieben werden, so dass jeder den des anderen auch versteht ;) Das geht bei so einfachen Sachen wie Formatierung los, aber auch Funktionsnamen, Klassennamen und die Aufteilung von Klassen auf Module sollte jeder nach dem gleichen Schema machen.

Da ich selber aber noch nicht mit mehr als 4 Leuten was gemacht hab, kann ich dir nicht mehr sagen. Sind aber Größenordnungen, da willst du ja noch gar nicht hin.

Jakob_Ullmann hat folgendes geschrieben :

Zum Beispiel, indem man Funktionen in verschiedene Module aufteilt, von denen jeder eins entwickelt.

Da geh ich lieber mit "Extreme Programming [http://chaosradio.ccc.de/cre028.html]", da wird eben nicht nach Funktionen sondern nach Features entwickelt. Das lässt sich prima aufteilen, und man vermeidet Konflikte. Kannst den Podcast ja mal durchhören, da gibts auf jeden fall was zu lernen.

Critter - Mo 18.01.10 17:59

Hallo,

mit Versionskontrollsystem solltest ihr euch auf jeden Fall auseinandersetzen ich Arbeite selbst an Solo Projekten nicht mehr ohne Subversion [https://secure.wikimedia.org/wikipedia/de/wiki/Subversion_%28Software%29]. Wenn man sich da erst einmal durchgebissen hat (anfangs ist es alles ein bisschen viel und man sieht nicht wirklich ein, wozu das gut sein soll) überwiegen die Vorteile erheblich.
Wenn generell die Möglichkeit besteht, dass die Arbeit des einen die des anderen Blockieren kann (und wo besteht die nicht ;)), dann solltest du dich auf jeden Fall im Rahmen deiner Studien zu Versionskontrollsystemen auch auf die Kapitel zu Branches konzentrieren. Die erlauben es z.B. deinem Vater an einer riesigen Änderung zu arbeiten, welche mehrere Wochen dauert, und dir ständig keine Neuerungen ins Projekt zu bringen und ihr behaltet trotzdem immer eine Kompilierbare Version, in der alle abgeschlossenen Teilprojekte schon drin sind ohne das auch nur eine halbfertige Funktion in dem Projekt herumschwirrt. Wenn ihr das ganze richtig angeht ist alleine das schon ein Segen.

Was user profile icon

Martok über die Kommunikation schrieb ist auch nicht unwichtig. Da ihr für euer Versionskontrollsystem wahrscheinlich ohnehin einen kleinen Server aufsetzen müsst, ist es sicher eine Überlegung wert diesem auch einen Apache [http://de.wikipedia.org/wiki/Apache_HTTP_Server] zu spendieren und noch ein Mantis [http://www.mantisbt.org] oder Flyspay [http://flyspray.org] auf zu setzen, und sei es nur, damit ihr keine Teilaufgabe vergesst und besser entscheiden könnt, welche neue Funktion in welche Version eurer Software einfließen soll.

critter

Critter - Mo 18.01.10 18:43

BenBE hat folgendes geschrieben :

Wozu den Apache? Mit Git geht Versionsverwaltung auch ohne Server ;-)

Der Apache sollte nicht für die Versionsverwaltung, sondern für den Bugtracker sein. Ich wollte nur darauf hinweisen, dass wenn Tim und sein Vater sich extra einen Rechner als Server hinstellen (was ja nicht unsinnig währe) dieser wahrscheinlich auch noch einen HTTP-Server nebst Bugtracker verkraftet und, dass eben auch diese, selbst in einem kleinen 2-Mann-Team sinnvoll sein kann. Ich wollte dem globalen Thema "Arbeiten im Team" so nur einen weiteren Aspekt hinzufügen.

critter

PS: Habe das Subversion auf meinem NAS auch ohne Apache laufen ;).

BenBE - Mo 18.01.10 18:49

Martok hat folgendes geschrieben :

UGrohne hat folgendes geschrieben :

Mit TortoiseSVN auch ;)

Nicht wirklich. Das Verzeichnis muss dann ja auch irgendwo liegen... Und in dem Fall irgendwo wo beide rankommen -> Server :P

Für SVN reicht ein Netzwerk-Share, ist aber bescheiden zu nutzen ...

Martok hat folgendes geschrieben :

Wollen wir noch weiter Haare spalten? Dann mach weiter, dann kann ich wenigstens sagen "der Co-Admin wars"... ^^

Gern ^^

dummzeuch - Mo 18.01.10 22:02

Sirke hat folgendes geschrieben :

Die zentralen Systeme sind meiner Information doch gar nicht mehr so aktuell, sodass SVN nach und nach von den Distributed Revision Control abgelöst werden: Ich habe gute Erfahrungen mit http://en.wikipedia.org/wiki/Mercurial gemacht!

Bei einem kleinen Team (in diesem Fall zwei) ist das ziemlich egal... Und Subversion ist ziemlich einfach zu benutzen. (Mercurial moeglicherweise auch, ich kenne es nur dem Namen nach).

twm

Critter - Di 19.01.10 11:42

Hi,

Sirke hat folgendes geschrieben :

das ist wieder diese Highlander Idee "es kann nur einen geben". Nein, Serverbasierte Systeme werden nicht von verteilten abgelöst werden. Beide haben ihre Existenzberechtigung und je nach Einsatzgebiet ist mal das eine, mal das andere sinnvoller. So werden z. B. die meisten Firmen lieber auf Server Basierte Systeme setzen, um an einem Zentralen Punkt den "ist" zustand aller Mitarbeiter zu sammeln. Bei Open Source Projekten die wahrscheinlich sehr breit in der Fläche gestreut sind, können verteilte Systeme sicher ihre stärken ausspielen.
Generell gibt es bei den Serverbasierten Systemen eigentlich nur einen Nachteil, dass sie einen Server benötigen und in der heutigen Zeit ist das für Firmen mit Sicherheit kein Problem mehr und auch in Privathaushalten kommen Integrierte Server immer häufiger zum Einsatz. Wie ober schon einmal erwähnt missbrauche ich mein (ständig laufendes) NAS als Subversion Server. Da ist eben auch nur ein Linux drauf und das kann genutzt werden. Ich denke nach und nach werden sich in viele Haushalte (zumindest in Programmierer haushalte) auf ähnliche Art zu missbrauchende integrierte Server einschleichen. Da Tims Vater aus der Brange ist, würde es mich auch nicht überraschen, wenn dort schon ein (richtiger) Server läuft, der nur eine weitere Aufgabe bekäme.

Aber wie gesagt, ich möchte hier niemanden sagen auf welches Pferd er zu setzen hat, es geht mir nur darum den Absolutheitsanspruch wieder ein wenig zu relativieren denn erfahrungsgemäß passiert es eben nicht, dass eine sehr gute Etablierte Technik durch eine neuere ersetzt wird. In der Regel finden beide ihre Nischen.

critter

Sirke - Di 19.01.10 13:30

Ich meinte auch nicht, dass Mercurial oder halt die verteilten Systeme nun zum Standard werden, aber in meinen Augen bieten diese gerade den Vorteil eines Servers und damit zentralen Repositories und vielen Repositories bei jedem Programmierer, welcher seine eigenen Versionen zusammensetzen kann. Gerade die Möglichkeit des eigenständigen Arbeites aller beteiligter Personen und das anschließende Zusammenfügen finde ich sehr interessant. Ich habe halt die Erfahrung gemacht, dass viele Entwicklungen weg von SVN gehen und hin zu Mercurial/DRC, sodass ich nur darauf hinweisen wollte und gerade junge Programmierer sich vllt mit beiden Systemen auseinander setzen sollten, auch wenn sie vom Prinzip her beide sehr ähnlich sind! ;-)

aksdb - Di 19.01.10 14:01

Rein serverbasierte System (CVS, SVN, ...) haben somit aber einen Nachteil, den DVCS eben nicht haben. Die kannst du auch zentral hosten (siehe Linux, OpenOffice.org, Mozilla, Netbeans, ....). Der Hauptvorteil von DVCS ist meines Erachtens das einfache Branchen. Jede Kopie des Repositories ist im Prinzip erstmal ein Branch in dem man sich austoben kann. Ist man dann mit seinen Änderungen fertig, kann man sie gebündelt (aber immernoch in überschaubaren einzelnen Changesets) an das zentrale Repository zurückübermitteln.
Seit ich von SVN auf Mercurial umgestiegen bin, hab ich erheblich mehr Changesets, weil ich einfach öfter commiten kann/will ... bei SVN ist das ja ein gräuel - a) langsam (im Vergleich zu HG) und b) bei jedem einzelnen Commit die Gefahr, sofort mergen zu müssen, weil jemand anders auch grad an der Datei bastelt.

Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2026 by Christian Stelzmann Alle Rechte vorbehalten.
Alle Beiträge stammen von dritten Personen und dürfen geltendes Recht nicht verletzen.
Entwickler-Ecke und die zugehörigen Webseiten distanzieren sich ausdrücklich von Fremdinhalten jeglicher Art!