So stellen Sie einem Kollegen Code vor


11

Wie gehen Sie vor, um einem neuen Mitglied Ihres Teams die Codebasis vorzustellen, die ziemlich komplex und mit vielen "Fallstricken" verbunden sein kann?

Ich denke, der einfachste Weg wäre, die Gesamtarchitektur mit Diagrammen zu gestalten und ein paar Wochen (oder Monate) damit zu verbringen, der neuen Person genau definierte (und gut definierte) Aufgaben zu geben, wenn sie sich an den Code gewöhnt.

Als Berater (und noch dazu Nachwuchskräfte) kann ich das jedoch nicht immer haben, weder aus zeitlichen Gründen noch aufgrund von Teamrollenbezeichnungen. (Ich war doppelt so lange an diesem speziellen Projekt wie jeder andere, daher weiß "junior" in keiner Weise "weniger über den Code / das Projekt".)

Ich wurde jetzt schon einige Male beauftragt, ein neues Mitglied in das Projekt und den Code einzuführen, und leider bin ich jedes Mal nicht viel besser darin als zuvor. Ich liebe Diagramme und Bilder, habe aber oft das Gefühl, dass sie die Komplexität eines Systems nicht angemessen berücksichtigen. (Was ist mit all den "Fallstricken" der Kleinen?)

Das Projekt kommt zu einem Punkt, an dem wir es an den Kunden weitergeben werden. Um die Dinge herausfordernder zu gestalten, ist die Person, mit der ich einen Wissenstransfer durchführen werde, im Wesentlichen gerade aus dem College. (Nicht, dass ich viel besser bin, wenn ich Wissenstransfers mit erfahrenen Entwicklern durchführe.)

Ich besuche einmal im Monat eine Benutzergruppe und andere sich bietende Gelegenheiten, sodass ich nicht ungewohnt bin, in neue Themen eingeführt zu werden, aber meine Fähigkeit, effektiven Wissensaustausch zu replizieren, für absolut unzureichend halte.

Jeder Rat wäre sehr dankbar. Ich suche hauptsächlich nach einer Richtlinie, der ich folgen kann. Zum Beispiel: Wo fängst du an? Wie gehst du vor? Wie decken Sie unbekannte Technologien oder Muster des Hörers ab, ohne sich den ganzen Tag Zeit zu nehmen? Wo verbinden Sie Geschäftslogik mit Codestruktur?

Vielen Dank!

(Wie immer können Sie die Frage nach Belieben bearbeiten.)


3
Es gibt keine Gründe, warum Sie Code kommentieren ...
Rig

4
@ Rig - ja, normalerweise mit# TODO: fix this ugly hack
detly

Antworten:


9

Schritt eins ist natürlich, die "Fallstricke" aus dem Code zu entfernen. Klarer, präziser und konsistenter Code ist einfacher zu verstehen, zu bearbeiten und zu debuggen.

Wo fängst du an?

Ich frage den Neuling, wie er in die Codebasis kommen will. Jeder lernt anders. Manche Leute mögen es, kleine Aufgaben zu haben, mit denen sie arbeiten können. Einige mögen das Debuggen von vorhandenem Code. Einige möchten, dass der Code ausgeführt wird, um zu verstehen, was er tut. Einige möchten am Einstiegspunkt beginnen und einfach herum navigieren. Einige wollen Visio-Diagramme ... Kein festgelegtes Muster wird für alle am besten funktionieren.

Wie decken Sie unbekannte Technologien oder Muster des Hörers ab, ohne sich den ganzen Tag Zeit zu nehmen?

Ich vermeide sie. Lassen Sie sie Black Boxes sein, bis der Neuankömmling nach ihnen fragt. Geben Sie dann gerade genug Informationen an, um sich ein Bild davon zu machen, mit dem Hinweis, dass sie in ihrer Freizeit mehr lernen können, oder fragen Sie später, wann das allgemeine Zeug bekannter ist.

Wo verbinden Sie Geschäftslogik mit Codestruktur?

Ich versuche, nicht. Es ist fast immer besser für den Neuankömmling, selbstständig zu lernen, damit es in einer Struktur in seinem Kopf sitzt, die für seine Denkweise natürlicher ist.


Eine Sache, an die Sie sich erinnern sollten, ist, die Anweisung kurz zu halten. Die Leute neigen dazu, ziemlich schnell auszuchecken, so dass weitere Anweisungen an diesem Punkt einfach nicht „haften bleiben“. Zeigen Sie ihnen die Dinge für 15-60 Minuten (verschiedene Personen haben unterschiedliche Aufmerksamkeitsspannen) und machen Sie dann eine Pause von 5-30 Minuten, damit sie sie verarbeiten können.


Je mehr ich mit dieser Person zusammenarbeite, desto mehr sehe ich, wie zutreffend Ihr Rat ist, irrelevante oder „fortgeschrittenere“ Themen vorerst nur zuzulassen und sie nicht einmal zu erwähnen.
Emragins

2

Nach meiner Erfahrung besteht eine gute Möglichkeit, die Lücke zwischen dem umfassenden Überblick, den ein Architekturdiagramm bietet, und den Details der tatsächlichen Arbeit mit dem Code darin, einen Drilldown des Systems durchzuführen, dh was passiert, wenn eine Anforderung eintrifft (für Servercode) ) oder ein Benutzer gibt eine Eingabe ein (für Client-Code) und erklärt dann Schritt für Schritt alle beteiligten Code-Ebenen.

Ein anderer Weg ist eine "Führung" durch den Quellcode, dh durch die Pakete / Namespaces / Module / Verzeichnisse gehen und erklären, was der Code in jedem von ihnen im Allgemeinen tut. Dies erfordert natürlich, dass der Code etwas logisch angeordnet ist.


1

Sie bringen ihnen nicht die Codebasis bei, Sie bringen ihnen Ihren Job bei. Versuchen Sie nicht zu überlegen, was sie brauchen könnten, sondern schauen Sie sich an, was Sie bei Ihrer Arbeit tatsächlich wissen müssen.

Rufen Sie die letzten Monate des Bug-Tracker-Verlaufs, Scrum-User-Storys, Statusberichte und Commits zur Quellcodeverwaltung auf. Welche Dateien haben Sie am meisten berührt? Welcher Code ist am problematischsten? Welche Aufgaben haben Sie am längsten gebraucht? Wenn Sie es in den letzten Monaten nicht berührt haben, ist es wahrscheinlich nicht so wichtig, wie Sie vielleicht denken.

Schauen Sie sich den Ausdruckstapel auf Ihrem Schreibtisch an. Überprüfen Sie Ihren letzten Browserverlauf. Suchen Sie nach gespeicherten E-Mails, auf die Sie häufig verweisen, verwendeten Kontakten und heruntergeladenen Dokumenten. Einige der nützlichsten Referenzen, die ich an andere weitergegeben habe, sind die Notizen, die ich beim ersten Erlernen oder Entwerfen des Systems für mich behalten habe. Welches Referenzmaterial ist für Sie am nützlichsten ?

Rufen Sie als nächstes Ihren bekannten Rückstand auf. Welche Dinge müssten Sie erforschen, um diese Aufgaben zu erledigen? Welche Codebereiche enthalten das Problem am wahrscheinlichsten? Übermitteln Sie diese Informationen, als würden Sie sich Notizen machen.

Wenn Sie in Ihrer täglichen Arbeit auf Diagramme oder Diagramme verweisen, schließen Sie diese ein. Wenn Sie sich noch nie die Mühe gemacht haben, eine zu erstellen, wird dies wahrscheinlich auch für Ihren Nachfolger / Kollegen nicht so nützlich sein.

Eine der schwierigsten Aufgaben beim Unterrichten ist es, sich in ihre Lage zu versetzen. In diesem Fall Sie sind in ihren Schuhen. Mach das Beste daraus.


Viele gute Ratschläge hier - bringt eine andere Perspektive auf Dinge, die helfen sollten. Vielen Dank!
Emragins

0

Support-Arbeit ist die beste, nehmen Sie einen einfachen Fehler und führen Sie sie durch die Bereiche, in denen sie gefunden werden. Sie werden schnell lernen, wie der Code zusammenpasst. Natürlich werden sie vorbeikommen, um Fragen zu diesem Fehler und der Codebasis zu stellen, aber sie werden dort ankommen (und Sie werden einen Fehler beheben lassen). Oft ist es viel einfacher, Dinge anhand von Beispielen herauszufinden, ähnlich wie es einfacher ist, eine Codebasis zu erarbeiten, indem man sie in einem Debugger durchläuft.

Wenn Sie sich über die Codeänderungen nicht sicher sind (oder dies normalerweise der Fall ist, bin ich mir meiner Codekorrekturen nicht sicher, bis ich mit der Codebasis vertraut bin), können Sie sie vor dem Einchecken überprüfen.

Natürlich sind Ihre bestehenden Vorstellungen von umfassenden Übersichten und Blockdiagrammen wesentliche erste Schritte.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.