spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Normalerweise hat in einem großen Entwicklerteam jeder eine bestimmte Aufgabe, der eine kümmert sich um Audio, der andere um Rendering, wieder ein anderer um das Netzwerk.

Dementsprechend kennt sich jeder in der Materie, an der er gerade rumschreibt, aus und fummelt nicht im Code von anderen rum.

Zum "Zusammenbringen" (mergen) des Codes benutzt man dann beispielsweise svn.

Such mal nach Subversion und GIT (git ist neuer und wird für neue Projekte empfohlen).

In der Regel werden Versionierungstools verwendet ala GIT/SVN/HG, ein "Live-Tool" ist mir nicht bekannt und ich habe auch noch nie die Notwendigkeit darin gesehen ein solches einsetzen zu wollen (es macht schlichtweg absolut keinen sinn)

Jup und Git kann man kostenlos auf GitHub oder Bitbucket hosten.

Es gibt schon so webbasierte Live-Coding Editoren. Aber die sind mehr für Spass gedacht und nicht wirklich für produktiven Einsatz.

Wie schon gesagt sind grosse Projekte, respektive die Tasks, die dort gemacht werden müssen mehr oder weniger gut aufgeteilt. Es programmieren also eigentlich nie 2 Leuten an der gleichen Funktion rum. Es kann aber schon passieren, dass 2 Leute kleinere Sachen in der gleichen Funktion ändern. Das muss dann in einem Schritt zusammengeführt (merge) werden und sollte am besten unter Aufsicht der beiden Entwicklern passieren, so dass sicher gegangen werden kann, dass alles korrekt verläuft.

Das solche Konflikte möglichst nicht passieren gibt es mehrere Techniken, die da helfen.
Zum einen sollte natürlich im vornhinein geschaut werden, dass nicht gleichzeitig mehrere Leute/Teams an der gleichen Funktionalität rumschrauben. Also es macht z.B. keinen Sinn, dass bei Facebook zwei Teams gleichzeitig den Nachrichten-Stream umbauen. Planung nennt sich das.

Zum anderen probiert man möglichst gegen Schnittstellen zu programmieren und abzubilden. Also sobald das Interface einer Klasse steht kann man sie benutzen und gleichzeitig kann da jemand die Funktionen implementieren. Es stört also gar nicht wenn da gleichzeitig dran gearbeitet wird. Zudem sind Funktionen wohl das feinste, was als Schnittstelle abgebildet wird und zu einem gegebenen Zeitpunkt wird jede Funktion wohl nur von jemanden bearbeitet (auch ein Grund warum man keine 200-Zeilen funktionen haben sollte). Aus der 200-Zeilen Funktion machst du also 20 10-Zeiler indem du die Funktionalität kapselst und Funktionen draus machst. Dann ist es auch kein Problem mehr, wenn da diese Funktionen gleichzeitig von mehreren Leuten bearbeitet werden.

Für den Fall dass es doch Konflikte gibt hat man üblicherweise Unit-Tests am laufen, die entdecken wenn jemand einen Bug eingeführt hat oder das Zusammenführen Fehlerhaft war.

Ganz gefeit gegen solche Merge-Konflikte und Bugs ist man allerdings nie. Als Beispiel der goto-Bug von Apple, der kürzlich in den Medien war (Verschwörungstheorien beiseite war das am wahrscheinlichsten ein solcher Merge-Fehler).

Ich hoffe das erklärt die ganze Sache ein wenig.

Mit dem Eclipse-Plugin Saros klappt die Zusammenarbeit in echtzeit ganz gut, ohne dass man auf IDE Funktionen verzichten muss.

Echtzeitzusammenarbeit ist aus meiner Sicht sogar sehr schlecht. Jeder Entwickler durchläuft mit seinem Code immerhin viele Stadien und muss viele Zeilen schreiben, ändern, entfernen oder ergänzen, bis sein Feature läuft (auch wenn Features KLEIN sein sollten!). Bis er damit aber durch ist, vergeht eben Zeit in welcher sein Code eventuell gar nicht übersetzt oder so viele Fehler produziert (weil eben noch nicht fertig), dass man damit gar nicht arbeiten kann. Damit würden sich alle Entwickler ja gegenseitig blockieren. Bei 2 Leuten kann man sich vielleicht noch absprechen (sofern man Skype hat oder nebeneinander sitzt), aber bei mehr geht das Chaos dann schon los und eigentlich kann dann keiner mehr ordentlich arbeiten und testen, weil die Sachen der anderen eben auch nie zum richtigen Zeitpunkt ausführbar sind.

Also hat jeder einen aktuellen Stand, wo er seinen Kram macht und wenn er fertig ist, überträgt er die Änderungen in eine zentrale Stelle (das Repository), wo andere die Änderungen wieder automatisch in ihren eigenen Code übertragen lassen können. So kann jeder selbst entscheiden, wann er etwas so reif hat, dass er es mit den anderen teilen kann - oder andersrum wann sein Code so reif ist, dass er die neueren Features aller anderen in seinen Code integrieren lassen kann, bevor er noch einmal final testet, um dann sein eigenes Zeug in das Repository zu übertragen.
Ein Projekt besteht im Üblichen aus vielen (20-5000+!) einzelnen Code-Dateien. In Java eben *.java Dateien.

Zitat von »thesimyo«

wie schafft man das ohne den Code komplett zu versauen?

Version control wurde ja bereits empfohlen, das funktioniert wunderbar wenn man mit einer hand voll Leuten am code arbeitet, dann kann man solche Sachen recht leicht absprechen. Wenn hunderte Leuten am Code rumfummeln wird version control alleine recht schwierig.

Aber auch dann gibt es einige Techniken mit denen man das Chaos minimieren kann:

- Automatisiertes Testen: Man kann unit tests schreiben die z.B. automatisch jede Nacht ausgefuehrt werden. Wenn die Tests fehlschlagen bekommen die verantwortlichen Leute eine E-Mail.
- Code Reviews: Jemand anderes aus dem Team schaut ueber deine Code Aenderungen um Fehler zu finden etc. Zusaetzlich gibts viele Projekte die jeder Datei einen Eigentuemer zuweisen, wenn du etwas an der Datei aendern moechtest, muss er im Code Review zustimmen.
- Continuous Integration: Die Aenderungen von allen Leuten kommen nicht direkt in das Zentrale Repository, sondern in eine Liste. Ein Server nimmt die ganzen Aenderungen aus der Liste dann und kompiliert das Projekt, fuehrt automatisierte Tests aus, etc. Wenn da etwas fehl schlaegt, dann werden die Aenderungen nicht akzeptiert.

Je groesser die Teams werden umso mehr Aufwand steckt in solchen Systemen, vor allem in den automatisierten Tests.