Die letzten Jahre habe ich überwiegend das "Visual C# 2010 Express"
und seit einem Jahr das "Microsoft Visual Studio 2010" verwendet.

Nun habe ich mir vergangenen Freitag mal die "Visual Studio Express 2013 Desktop" installiert
und bei "Visual Studio Online" ein kostenloses Team angelegt.

Ich möchte damit mal die Team Geschichten ausprobieren und gemeinsam mit einem Kumpel,
ein par kleine Spielchen wie z. b. "Tic Tac Toe" basteln.

Ich hoffte eigentlich auf eine Möglichkeit für Paralleles arbeiten an der selben Datei,
ähnlich wie es das Instant Review Addon für viel Geld ermöglicht.

Jetzt ist mir aber klar geworden, das diese Team Arbeit mit ihrer Aufgabenverteilung
und den quasi unendlich komplexen Möglichkeiten nichts fürs Hobby ist.

Vor allem aber wegen dem Ein- und Auschecken von Dateien,
was wirkliches gleichzeitiges arbeiten an der selben Datei nicht möglich macht.

------------------------------------------------------------------

Kennt jemand von euch eine Alternative die mir das ermöglicht was ich gerne hätte
und die preislich den Rahmen, für nicht kommerzielle Hobbyprogrammierer, nicht sprengt?

Genau genommen suche ich nach einer Möglichkeit das zwei oder mehr Nutzer das selbe Dokument öffnen können,
dabei werden die Änderungen des jeweils anderen solange eingefärbt dargestellt und live aktualisiert
bis dieser sie speichert womit sie für die anderen Bearbeiter fix werden.

Klar Objektorientierung hin und her, Funktionen und Klassen sollten ausgelagert werden ...
aber gerade wenn man nicht so erfahren ist, hilft es meist wenn ein zweiter
kurz mal über das drüber kucken kann was man gerade quellcodetechnisch verbrochen hat.

Würde mich freuen falls wer ne Lösung kennt die nicht gerade auf einem Browser mit SkyDrive basiert.

Gruß,
avoid

Ich weiß nicht, ob das wirklich möglich ist.
Wenn man an einer Datei arbeitet, hat man zwischendurch immer Stände, die nicht kompilierbar sind, oder die nicht funktionsfähig sind. Daher solltet ihr über die Aufgabenverteilung sprechen und diese Aufgaben so verteilen, dass sich das nach Möglichkeit auch in der Programmstruktur wiederspiegelt.

Das heißt, der eine kümmert sich z.B. um die Highscoreliste. Diese Funktionen werden in der Unit "Highscore" ausprogrammiert. Der andere kümmert sich um den Computergegner. Dies wird in der Unit "AI" ausprogrammiert. Jetzt macht jeder seine Arbeit. Wenn man einen Programmteil fertig hat, dann gibt es mehrere Möglichkeiten:
1. ihr setzt euch zusammen und stöpselt gemeinsam die Programmteile zu einem großen Ganzen zusammen.
2. ihr bestimmt einen "Hauptentwickler", der die Änderungen zusammenbaut
3. jeder integriert seine Änderungen selbst und allein ins Programm

bei 3. ist die Gefahr für Kollisionen am größten. Da müsst ihr euch absprechen. Auschecken, Einbauen, Einchecken.
Wenn es dabei doch Kollisionen gibt, muss derjenige, der zuletzt eincheckt, die Kollision auflösen (die Änderungen zusammenführen).

Eine weitere Möglichkeit besteht noch. Das wäre, zu Beginn die nötigen Funktionen, etc. festzulegen. Die legt ihr dann leer an, also nicht ausprogrammiert. Dann könnt ihr die Programmteile schon zu Beginn zusammen setzen, allerdings noch ohne Funktion. Dann kann jeder für sich in seinem stillen Kämmerlein die Funktionen ausprogrammieren.
Diese Möglichkeit erfordert meiner Meinung nach die größte Erfahrung, da dann schon zu Projektbeginn möglichst genau feststehten muss, wie die Programmkomponenten zusammen arbeiten werden. Von daher halte ich diese Vorgehensweise grade für Hobbyprogrammierer nicht für die beste.

Egal, für welche Möglichkeit ihr euch entscheidet. Wichtig ist, dass ihr das Projekt strukturell untereinander aufteilt.

danke für die Antwort.
derartiges hab ich mir schon gedacht, aber trotzdem noch gehofft.

da muss ich wohl selbst einen kleinen Code Editor bauen.
IntelliSense kann man nicht zufällig in eigene Anwendungen integrieren?
denn das würde ich schon vermissen wenn ich was eigenes erstelle.

Also gleichzeitig an der selben Datei schreiben - bloß nicht, das führt nur zu Problemen. Ein Review geht natürlich, das finde ich aber auch nicht unbedingt gut, weil dann nur einer da sitzt, unproduktiv zu schaut und im schlimmsten Fall ständig irgendwas kritisiert. Wenn jemand nicht weiter kommt, ist es sowieso besser, wenn die Lösung des Problems nicht vor gesagt, sondern selber gefunden wird. Der Lerneffekt ist größer und das kann sehr motivierend sein.

Macht es lieber so, dass der Eine dem Anderen mit teilt, was er fertig hat und der schreibt dann ein ausführliches aber sachliches Review zu dem Code.
Das hat den Vorteil, dass derjenige, der das Review macht, gezwungen ist, sich komplett in den Code rein zu denken. Wenn er das mühelos und schnell schafft, dann ist schon einmal viel richtig gemacht, wenn das schwer wird, dann gibt es im Regelfall Möglichkeiten, etwas besser und übersichtlicher zu schreiben. Das muss dann der Reviewer heraus finden und dem Autor der Klasse darlegen, damit er daraus lernen kann. Ladet aber nicht riesige Haufen zum Review auf. Eine Klasse Maximum, sonst wird das zu viel auf Einmal und es soll ja auch noch irgendwo die Motivation da sein, das auch zu machen.

Vergesst aber auch nicht die Planung, ein Team fordert eine gewisse Planung, damit es harmonieren kann. Bei zwei Leuten wird das nicht so krass sein, aber es wäre für euch beide viel einfacher, wenn ihr euch vorher überlegt, was das Programm können soll, wie es das machen soll und wie die Architektur des Programms aussehen soll. Stehen schon vorher die Klassen und deren Funktion fest, dann legt ihr einmal am Anfang alle diese Klassen an - ohne Inhalt, nur leere Methoden - und dann programmiert ihr dort Stück für Stück das Programm aus.

Auf diese Weise kommt ihr euch nicht unwillentlich in die Quere und könnt effektiv zusammen arbeiten. Jeder nimmt sich dann z.B. eine bestimmte Klasse, programmiert sie komplett aus, testet sie, optimiert sie und erst wenn sie fertig ist, macht der Andere ein Review, während der Erste sich die nächste Aufgabe nimmt. So läuft das dann immer weiter und im Idealfall, wenn die Planung vorher korrekt abgelaufen ist und dabei keine Fehler in der Architektur gemacht wurden, dann habt ihr im Nachhinein es viel einfacher und ihr lernt ständig voneinander.



So ähnlich arbeiten wir schon lange, wir arbeiten dabei nach Scrum und jeder Task wird erst dann durch gewunken, wenn alle Tests + dem Test für die Änderung/Erweiterung laufen und min. ein Kollege ein Review von dem Code gemacht und durch gewunken hat. Wir arbeiten dabei etwas anders, als ich oben erklärt habe, allerdings haben wir auch Ultimate zur Verfügung und das Team ist deutlich größer. EIn strenges Vorgehen nach Scrum wäre für euch gar nicht sinnvoll, aber so ein paar Grundzüge sind nicht verkehrt.




Ich finde es aber gut, dass du dir da so Gedanken machst. Manchmal gibt's im Internet Code, der tut fast schon weh.
Natürlich fängt jeder mal an, aber auf diese Weise - mit den Reviews - werden so manche Code-Sündern (auch von Anfängern) ziemlich schnell aus dem Projekt verbannt, weil z.B. eine eng zusammen gequetschte und riesige Methode, die alles tut, nicht leicht zu verstehen ist. Ist diese Methode aber in logische Teilbereiche der Hauptaufgabe unterteilt, dass da viele kleine handliche Methoden stehen, sind die locker und in einem Ritt gelesen und im Idealfall auch verstanden. Außerdem sieht ein Team immer mehr, als Einer alleine.



Gruß

Ich danke auch dir für deine Antwort.

"scrum" trifft eig. schon recht gut meine generelle Arbeitsweise beim programmieren.

- ich habe idr. ein Projekt das ich in Teilbereiche gliedere.
- die Teilbereiche formuliere ich dann grob aus und mach mich an die Arbeit.
- nach der Erstellung des grob ausformulierten Grundgerüst des Projekts,
arbeite ich die einzelnen Teilbereiche immer detaillierter aus.
- dabei zieht beinahe jede detailliertere Ausarbeitung eines Teilbereichs
weitere Ausarbeitungen anderer Teilbereiche nach sich.
- Das Projekt wächst quasi an sich selbst.
- Leider setzt das eine eingebaute Reißleine gegen Detailverliebtheit voraus,
sonst würden meine Projekte nie fertig werden.

das hab ich mir durch meine vielen solo Programme so angeeignet.
für Teamarbeit werde ich also umdenken müssen, das hab ich verstanden.

Also ich habe so eine "synchrone Programmierung" schonmal aus Versehen gehabt. Da waren die Quelldateien in Dropbox (oder so) und ich und ein Freund haben gleichzeitig programmiert.

War ganz doof - weil ich ständig fand "so, das könnte jetzt gehen" oder "oh, mal gucken was da so für werte ankommen" und versuchte das Programm auszuführen. Das wiederum verhinderten natürlich die (zu diesem Zeitpunkt unvollständigen) Änderungen vom anderen. Wir haben den Quelltext dann ganz schnell von der Cloud getrennt

Für Code erklären oder so fände ich Software sinnvoller, die den Bildschirm teilt und Mausbewegung ermöglicht, wie TeamViewer.