Realtime Collaboration in IDEs

Hat jemand von euch schon wirklich produktiv mit Realtime-Collaboration in einer IDE gearbeitet, also à la Live Share, Code With Me oder ähnlichem? Ich find die Idee super: weniger „kannst du mal eben deinen Screen teilen?“ und direkt gemeinsam am Problem sitzen.

Mich würde interessieren, wo für euch der Mehrwert liegt – Pair Programming, Support, Onboarding, Code Reviews? Und ab wann wird’s eher chaotisch, wenn plötzlich zwei Leute gleichzeitig dieselbe Datei anfassen?

Ich hab Live Share ein paarmal für Fehlersuche und Onboarding genutzt, dafür ist es echt gold wert. Gerade wenn der andere direkt Breakpoints setzen, Logs anschauen oder mal schnell eine kleine Änderung testen kann, spart das dieses ewige „scroll mal da hin“-Gelaber. Für richtiges Pairing würde ich aber klar Fahrer/Navigator festlegen, sonst tippen beide halb gleichzeitig und am Ende weiß keiner mehr, warum der Code jetzt so aussieht.

Bei uns hat sich bewährt: eine Person schreibt, die andere kommentiert bzw. markiert Stellen. Wechsel nach 20–30 Minuten oder wenn man festhängt. Nutzt ihr das auch über Remote-Container/WSL hinweg? Da hatte ich je nach Projekt schon nervige Unterschiede bei Pfaden und lokalen Tools.

Sehe ich genauso: Für Fehlersuche ist dieses „scroll mal da hin“-Gelaber wirklich der größte Gewinn. Fahrer/Navigator klingt erstmal formell, verhindert aber genau das Chaos, vor dem ich oben gefragt hatte. Der Wechsel nach 20–30 Minuten ist auch ein guter Trick gegen Tunnelblick – und fürs Onboarding lernt die neue Person nicht nur den Code, sondern gleich die Denkweise dahinter.

Remote-Container/WSL habe ich damit bisher nur testweise genutzt. Grundsätzlich klappt’s, aber ich würde vorher klären, wer Zugriff auf welche Secrets, Datenbanken und lokalen Dienste bekommt. Gerade bei Support-Sessions ist ein abgespecktes Dev-Setup vermutlich entspannter als dem Gast versehentlich die halbe lokale Umgebung freizugeben.

Bei Produktionsbugs wäre für mich deshalb die Trennung wichtig: gemeinsam den Code und die Requests anschauen, aber nicht unbedingt die komplette lokale Umgebung teilen. Idealerweise läuft die Session in einem Dev-Container mit festem Compose-Setup und einer klaren `dev.env.example`. Feature-Flags, Locale, Zeitzone und Datenbankstand sollten dabei möglichst dokumentiert bzw. reproduzierbar sein – sonst debuggt man am Ende zwei verschiedene Anwendungen.

Was ich bei solchen Sessions zusätzlich hilfreich finde: vor dem Start einmal den aktuellen Git-Stand und die aktiven Flags festhalten, danach den Diff gemeinsam durchgehen und die Änderungen nicht einfach im Workspace liegen lassen. Gerade bei Live Share vergisst man schnell, dass der Gast eventuell Dateien geändert oder Prozesse gestartet hat. Für sensible Projekte würde ich auch Gastzugriff standardmäßig read-only lassen und Schreib-/Terminalrechte nur kurz für den konkreten Schritt freigeben.

Für Reviews finde ich Realtime-Collaboration dagegen etwas zwiespältig. Es ist super, wenn man eine komplexe Stelle gemeinsam durchdenkt, aber als Ersatz für einen normalen PR-Prozess taugt es meiner Meinung nach nicht: Kommentare, nachvollziehbare Commits und ein späterer Review-Blick fehlen sonst. Bei uns wäre der Ablauf eher „gemeinsam analysieren und einen kleinen Fix bauen“, danach sauberer PR mit Tests und zweitem Review.

Wie habt ihr das mit den Berechtigungen gelöst – nutzt ihr dafür feste Rollen/Session-Profile oder wird das jedes Mal manuell eingestellt?

Der Punkt mit dem festgehaltenen Git-Stand ist echt wichtig. Ich würde vor einer Session noch eine kleine Checkliste dazunehmen: Branch/Commit, Feature-Flags, Zeitzone/Locale, verwendete Container-Version und wer Terminal bzw. Debugger bedienen darf. Sonst landet man schnell bei „bei mir geht’s“ – nur eben mit zwei unterschiedlichen Zuständen. Für sensible Projekte wäre mir außerdem wichtig, dass der Zugriff nach der Session wirklich beendet und idealerweise protokolliert wird.

Bei uns hat sich für Code Reviews eher eine geteilte Session mit nur einem „Schreibrecht“ bewährt, während der andere kommentiert. Fürs Onboarding darf der Neuling dann ruhig selbst fahren, auch wenn es langsamer ist. Nutzt ihr für solche Sessions eigentlich integrierte Chat-/Kommentarfunktionen der IDE oder läuft die Kommunikation trotzdem über Teams/Discord?

Die feingranulare Rechtevergabe ist für mich auch der Punkt, an dem die Tools noch etwas erwachsen werden müssten. „Kann Code ändern“ und „kann beliebige Shell-Befehle ausführen“ sind halt zwei völlig verschiedene Risikoklassen. Ich würde mir pro Session ein einfaches Profil wünschen: Review nur lesen, Pairing schreiben aber kein Terminal, Debugging zusätzlich Breakpoints/Logs – und alles mit Ablaufzeit statt dauerhaftem Zugriff.

Bei uns hat sich bei kurzen Hilfesessions übrigens bewährt, dass der Gast gar nicht auf der laufenden Umgebung arbeitet, sondern nur einen isolierten Container bekommt. Das war anfangs etwas langsamer, hat aber einige Diskussionen über lokale Konfigurationen erspart. Schwieriger wird’s bei interaktiven Debuggern: Da muss einer den Prozess wirklich steuern, sonst setzt der eine gerade einen Breakpoint, während der andere weiterklickt. Wie handhabt ihr das – feste Rollen auch beim Debugging oder einfach Absprache im Call?

Das „etwas langsamer“ am Anfang wird meiner Erfahrung nach schnell günstiger als die Fehlersuche in einer halb geteilten lokalen Umgebung. Gerade bei Support-Sessions wäre ein standardisiertes Session-Profil praktisch: Zweck, erlaubte Aktionen, Ablaufzeit und danach automatisch ein kurzer Export von Commit, Container-Image und eventuell ausgeführten Befehlen. Nicht als Überwachung, eher damit man später noch weiß, was tatsächlich passiert ist.

Was ich noch spannend fände: Wie geht ihr mit Änderungen während der Session um? Bei Pairing ist gemeinsames Schreiben klar, aber bei einer spontanen Bugfix-Session würde ich wahrscheinlich erst einen temporären Branch oder Patch erzeugen und erst danach bewusst mergen. Sonst ist die Grenze zwischen „wir untersuchen das“ und „jemand hat nebenbei den Code verändert“ ziemlich schnell verwischt. Habt ihr dafür feste Regeln oder reicht bei euch Absprache im Chat?