Neue Teammitglieder besser integrieren

Es ist Montagmorgen, 8 Uhr. Du hast gerade das Gebäude deines neuen Arbeitgebers betreten und bist ein wenig nervös. Wenige Augenblicke später sitzt du bereits vor einem Computer in einem Raum mit deinem neuen Team. Alle haben sich dir vorgestellt und sind froh, dich an Board zu haben. Nachdem du alle benötigten Geräte eingerichtet, die Monitore eingestellt und den ersten Kaffee getrunken hast, willst du anfangen produktiv zu sein. Du fragst nach einer Aufgabe und ein Kollege weist dir ein Ticket zu. Aber was nun? Du fragst nach der Dokumentation und nimmst dir die Zeit, den Code zu durchstöbern. Du stellst vielleicht sogar ein paar Fragen, aber kommst nicht wirklich weit, ohne noch mehr zu fragen. Langsam bahnst du dir den Weg durch die Codebase, startest den Debugger, und triffst von Zeit zur Zeit auf Probleme. Es scheint, als ob man in einem Labyrinth feststeckt.

Das ist eine Situation, die in vielen Teams durchaus üblich zu sein scheint. Von neuen Entwicklern, die zum Team stoßen, wird erwartet, dass sie sich irgendwie durchschlagen und die Dinge selbst herausfinden.

Während jeder Entwickler wahrscheinlich in der Lage ist, Code zu lesen, zu debuggen und zu verstehen, ist es wirklich schwer, alle Zusammenhänge in einer neuen Codebasis zu verstehen.

Situationen wie diese sind wirklich frustrierend und kosten viel Energie. Je nachdem, wie lange der neue Mitarbeiter braucht, um sich mit dem Code und der Infrastruktur vertraut zu machen, kann dies auch das Unternehmen einiges an Geld kosten.

Wie kann man diese Situation verbessern?

Um ehrlich zu sein, ist es ziemlich einfach. Es gibt einige Dinge, die jedes Teammitglied tun kann:

1. Erstellen eines Kontextdiagramme für das System und alles, was damit verbunden ist.

   • Was sind die Abhängigkeiten?
   • Was sind die Verantwortlichkeiten?

2. Erstellen eines Schaubilds, das zeigt, wie der Code strukturiert ist.

   • Werden Architektur- und Designmuster verwendet?
   • Welche schichten gibt es im System?

3. Schreiben einee Dokumentation für kritische Teile der Software.

   • Wie kann dieser Teil des Codes erweitert werden?
   • Welche Probleme gab es bereits mit diesem Teil des Codes?
   • Was sollte ich unbedingt wissen, wenn ich diesen Code anrühre?

4. Kommentare im Code hinzufügen.

   • Nicht alles muss kommentiert sein.
   • Kommentare sollten immer nur das “warum” und nicht das “was” beschreiben.
   • Interfaces sollten einen Kommentar zu jeder Funktion und einen Kommentar auf oberster Ebene haben, um ihre Verantwortung zu erklären.

5. Verwenden von Guidelines zum Schreiben von Code.

Die Liste enthält nur ein paar Beispiele dafür, was wir tun können, um anderen zu helfen, unsere Codebasis und Systeme besser zu verstehen. Denke immer daran, dass alle Punkte auf der Liste zu zusätzlicher Wartung führen kann und auf dem neuesten Stand gehalten werden will. Sei also vorsichtig, um deine tägliche Arbeit nicht zu sehr zu belasten.

Pair Programming

Alle oben genannten Lösungen verursachen zusätzliche Arbeit und sind nicht wirklich gut skalierbar, aber es gibt einen anderen Ansatz, den wir wählen können. Wir können uns zusammensetzen und zu zweit Code schreiben, debuggen und lesen!

Wir können einen Junior und einen Senior zusammenbringen, um beiden zu helfen, sich weiterzuentwickeln - der Junior lernt von dem Senior und der Senior festigt sein Wissen und lernt, es weiterzugeben. Wir können auch zwei Junioren zusammenbringen, damit sie gemeinsam lernen können. Und wir können sicherlich auch zwei Senioren zusammenbringen, damit sie Lösungen für die komplexesten Probleme finden können. Wir können auch Tester und Entwickler oder Entwickler und Designer zusammenbringen. Die Möglichkeiten sind nahezu endlos, und alle führen dazu, dass man sich gegenseitig hilft, zu wachsen und zu lernen.

Wir können jetzt auch die Review für einen Pull-Request überspringen, nachdem wir ein Feature implementiert haben, weil sich bereits zwei Leute darum gekümmert haben, wodurch zusätzliche Zeit gewonnen wird.

Einige Leute werden versuchen zu agumentieren, dass es das Team verlangsamen könnte oder dass es zu viel kostet. Das ist meiner Meinung nach aber nicht der Fall. Es dauert vielleicht eine Weile, bis du dich daran gewöhnt hast, aber du wirst jedes Mal besser darin zusammen zu arbeiten. Hoffently wirst du feststellen, dass die Entwicklungsgeschwindigkeit und die Codequalität bei euch zunimmt und die Wissensinseln abnehmen! Dabei wird außerderdem neuen Teammitgliedern geholfen, sich schneller zurecht zu finden.