Es gibt einige Dinge, die mir beim Empfang von Codeüberprüfungen sehr geholfen haben:

Sagen Sie nicht "Sie" oder Variationen davon ("Ihr Code"). usw.)

Sie zerreißen nicht "seinen" Code oder "seine" Lösung. Es ist unser Code oder diese Lösung, und wir müssen etwas dagegen tun.

Sobald jemand anfängt Wenn Sie über "Ihren" Code sprechen, besteht die natürliche Reaktion vieler Menschen darin, defensiv oder sogar kämpferisch zu werden - insbesondere, wenn sie sich zunächst nicht sehr sicher fühlen. Wenn Sie vermeiden, dem Junior-Entwickler das Eigentum an dem Code zu implizieren, fühlen sie sich weniger angegriffen. Schließlich besitzt das Unternehmen den Code.

Verwenden Sie stattdessen eine Sprache, die deutlich macht, dass das Team zusammenarbeitet, um sowohl die Qualität des Produkts als auch die Fähigkeiten der Teammitglieder zu verbessern.

Verwenden Sie eine positive Sprache und vermeiden Sie es, so viel wie möglich negativ zu sein.

Zum Beispiel, anstatt darüber zu sprechen, warum die vom Junior gewählte Namenskonvention lautet schlecht, sprechen Sie über die Vorteile der Konvention, die Sie empfehlen.

Ähnlich wie bei logischen Problemen, anstatt ewig darüber zu reden, wie schlecht die erste Lösung ist, berühren Sie schnell die Hauptprobleme, aber geben Sie die Mehrheit aus der Zeit, um einen besseren Weg zu erklären, und die Vorteile, die mit dem zweiten Weg verbunden sind.

Ich war oft in einer solchen Situation. Und das erste, was ich normalerweise sage, ist: Entschuldigung ...

Ja, richtig ... denn wenn er die einfachsten Dinge nicht richtig verstanden hat, wie Namenskonventionen, bedeutet das, dass Sie (oder wer auch immer dafür verantwortlich war) für ihn) hat es nicht gut gemacht, sie ihm vorzustellen ...

Entschuldigen Sie also, dass Sie ihm nicht genügend Informationen gegeben haben, um einen guten Job zu machen. Auch wenn dies nur teilweise zutrifft, wird er sich dadurch verstanden fühlen und er wird sehen, dass Sie ihn nicht für etwas verantwortlich machen wollen, das er falsch gemacht hat, sondern sich gemeinsam als Team als Lernprozess für Sie beide verbessern möchten.

Wenn Sie dann den Code durchgehen, ist es das Wichtigste, dass er seine logischen Fehler versteht, anstatt ihm zu sagen, was los ist.

Ich persönlich verwende so etwas wie „Gummiente“ Debuggen “in diesem Fall: Lassen Sie ihn erklären, was sein Code tun soll. Jetzt gibt es zwei Möglichkeiten:

Erstens: Wenn sein Verständnis der Aufgabe richtig ist, der Code jedoch falsch, gehen Sie tiefer

Versuchen Sie, ihm klar zu machen - indem Sie ihm Fragen zu „Was wird der Code tun, wenn ...“ stellen -, was mit dem Code nicht stimmt, und lassen Sie ihn versuchen, ihn zu beheben selbst. Das Gleiche gilt für die Variablen: Fragen Sie ihn, welche Namen er ihnen jetzt geben würde, nachdem Sie ihm die richtigen Namenskonventionen beigebracht haben.

Zweitens: Wenn sein Verständnis dessen, was empfohlen wurde, bereits falsch ist, erklären Sie ihm, was die Bei der Aufgabe ging es wirklich darum, ihn erklären zu lassen, wie er das umsetzen würde.

Auf diese Weise zerstören Sie seine Lösung nicht, sondern lassen ihn sie selbst verbessern. Und selbst wenn sich der neue Code nach dieser Zeit zu 100% von dem unterscheidet, was er zuerst hatte, ist dieser neue Code immer noch „sein“ Code.

TL; DR: Übernehmen Sie die Verantwortung für die Qualität des Codes durch Ich entschuldige mich dafür, dass ich ihm nicht genug gesagt habe, was ich tun soll / was mich erwartet, und lasse ihn dann seinen Code selbst korrigieren.

Mit anderen Worten (sehr berühmtes Zitat):

Sag es mir und ich vergesse,
lehre mich und ich erinnere mich,
involviere mich und ich lerne

Bestehen Sie zunächst nicht darauf, Feedback zu nehmen und daraus zu lernen .

Insbesondere das Nicht-Notieren auf Papier ist nicht unbedingt ein Zeichen dafür, dass der Junior nichts / genug aus der Codeüberprüfung herausholt. Bei den meisten Codeüberprüfungen im "Programmierstil" habe ich noch nie Notizen in Papierform gemacht, da ich mich eher darauf konzentriere, über den Code zu sprechen und über die "Regeln" und ihre Vorteile in dieser Zeit nachzudenken, in der ich jemanden habe, der dies direkt neben mir bespricht beschäftigt sein, Sachen aufzuschreiben. Und ich habe die "Notizen" trotzdem - im Code-Repository! (Zumindest hätte ich das tun sollen!). Wenn ich mich auf das eigentliche Thema konzentriere, kann ich viel mehr als nur Dinge aufschreiben und dann das Stück Papier auf einen Haufen anderer Notizen werfen, um es nie wieder anzusehen. Wenn ich gezwungen wäre, Notizen zu machen, würde ich dem Meeting nur entnehmen, dass ich nicht gerne mit diesem Senior zusammenarbeiten würde, weil es ihm nur darum geht, alles auf seine Weise zu haben.

Also: Ja, bitte schlagen Sie Optionen vor, z. indem Sie fragen, ob der Junior sein Notizbuch benötigt, aber nicht Ihre Lernmethode auferlegen. Stellen Sie vielmehr so ​​weit wie möglich sicher, dass der Junior die relevanten Informationen danach ohnehin zur Verfügung hat - z. indem Sie die Namenskonventionen irgendwo in ein Wiki schreiben, damit jeder sie nachschlagen kann, und indem Sie die in der Überprüfung identifizierten notwendigen Änderungen - oder zumindest einige Beispiele - in einen Überprüfungszweig übernehmen.

Wenn Sie im Moment nur mündlich Codeüberprüfungen durchführen und dem Junior erklären, was er in einem Gespräch falsch gemacht hat, würde ich dringend empfehlen, entweder direkt sicherzustellen, dass Änderungen vorgenommen werden, die Sie im jeweiligen Code vorschlagen, oder den Junior dazu zu bringen, dies zu tun Änderungen und überprüfen Sie den Code erneut. Im letzteren Fall sollten Sie den Nacharbeitsaufwand pro Sitzung gering halten und stattdessen mehrere Sitzungen durchführen. Wenn Sie die Änderungen bereits vorgenommen haben, weisen Sie sie im Code-Repository darauf hin, dass sich der Junior eher an die Orte als an zufällige Beispiele erinnern kann, die nicht mit Ihrer täglichen Arbeit verbunden sind.

Zeigen Sie ihm, dass er nicht allein ist, gehen Sie an die Öffentlichkeit.

Ich stimme der Antwort von Player One zu und würde dies tun Fügen Sie noch einen Vorschlag hinzu: Haben Sie nicht nur Code-Reviews bei sich. Machen Sie Codeüberprüfungen zu einem offiziellen regulären Bestandteil Ihres Prozesses und führen Sie sie mit allen durch.

Wenn Sie der Meinung sind, dass er defensiv ist, führen Sie (einige) Codeüberprüfungen mit der gesamten Gruppe durch. Beginnen Sie jedoch mit einigen Ihrer älteren Kollegen und behandeln Sie sie genauso, wie Sie ihn behandeln würden: Sprechen Sie über ihren Code , nicht die. Es gibt fast immer etwas, über das es sich zu diskutieren lohnt, auch im Code von Senioren. Und wenn es nur um "Ja, es wird wegen a), b) und c) so gemacht, aber man hätte es allgemeiner machen / Prinzip X folgen können, indem man Z macht, aber das hätte den Nachteil Y". Stellen Sie sicher, dass Sie für alle den gleichen Ton und die gleiche Neutralität verwenden. Dies zeigt dem Junior, dass Sie nicht versuchen, ihn mit Ihren dummen Regeln zu schikanieren, sondern dass jeder unter der gleichen Kontrolle steht und dass es nicht "Ihre" dummen Regeln sind, sondern die gemeinsamen Regeln des Teams - vorzugsweise basierend auf den Vorteilen des Teams als Ganzes mag haben. Darüber hinaus kann der Junior auch aus den Fehlern (oder großartigen Designentscheidungen) anderer lernen. Das macht es für ihn noch weniger persönlich und gibt ihm die Möglichkeit, sich mit anderen Geschäftslogikbereichen und Software-Prinzipien in Verbindung zu setzen, bevor er daran arbeiten muss. Daher hat er möglicherweise die notwendige Zeit, um sie zu "verdauen", bevor er sich bewerben / bearbeiten muss sie.

Wenn jemand auf Anfängerebene schlecht spielt, bedeutet dies nur, dass er die Grundlagen verstehen muss. Ich analysiere ihre Fehler nicht und versuche, sie so zu lehren. Ich habe diese bereits gelöst, und es gab wahrscheinlich ein bisschen Fluchen in so alten Nachrichten.

Ich habe nur die Grundlagen im Detail durchgearbeitet. Damit meine ich die Konventionen, Verfahren usw. Wichtig ist, dass ich ihm vor dem Start beibringe, wie man ein Projekt plant, und ich werde das nächste überprüfen. Sie bringen ihre Probleme zu mir, wenn sie etwas nicht verstehen.

Ich möchte ihn nicht damit beeindrucken, wie gut ich bin. Ich möchte, dass er lernt, wie man Dinge erledigt, ohne dass ich zusätzlich zu anderen Aufgaben babysitten muss.

• Wichtige Probleme in der Logik, mangelndes Wissen darüber, wie ein Problem auf die Grundursache zurückgeführt werden kann, und sehr undurchsichtige Namenskonventionen (dies war aufgrund der Art des Projekts sehr problematisch) / li>
  / blockquote>

  Ich würde mit dem einfachsten zuerst beginnen.

  "Namenskonventionen"

  • Ihr Unternehmen verfügt wahrscheinlich über einen Leitfaden. Das Buch Code Complete 2 kann auch eine ziemlich gute Anleitung sein. Es erklärt das Warum und gibt eine Checkliste.
  • Ich würde ihn dazu bringen, seinen eigenen Spickzettel zu erstellen und ihn auf seinen eigenen Computermonitor kleben zu lassen.
  • Wenn er es sich nicht zur Gewohnheit macht, die Unternehmenskonventionen oder seinen eigenen Spickzettel zu befolgen. Zwingen Sie ihn, ein Papier- und Bleistiftlexikon aller Variablennamen zu führen, die er in einem Tabellenformat verwendet. Auch das sollte immer an seinem Schreibtisch neben seiner Tastatur sein.

  Als nächstes würde ich mich mit der Frage befassen, wie man ein Problem auf die Grundursache zurückführt.

  Dies ist kein einfaches Problem, es wird wahrscheinlich mehrere Sitzungen dauern, um jede Technik umfassend zu behandeln. Du kannst ihn auch nicht überstürzen. Selbst wenn Sie ihm alles auf einmal erzählen, wird er nicht alles auf einmal aufnehmen.

  Es ist sogar möglich, dass er bereits weiß, was zu tun ist, aber diese Dinge einfach nicht tut. Sie sollten ihn also zu diesen Themen befragen und sehen, wie er diese Probleme in der Praxis mit minimaler Anleitung von Ihrer Seite behandelt.

  Zum Problem "Hauptprobleme in der Logik". Das sind Ergebnisse. Wenn Sie ihm helfen, die zugrunde liegenden Prozesse zu reparieren, die er verwendet, sollten sich die Ergebnisse verbessern. Sie können seine logischen Fehler erklären, wenn Sie möchten, aber erwarten Sie nicht, dass dies ausreicht.

  Betrachten Sie sich als Lehrer. Sie können einen Schüler nicht mit zu vielen Korrekturen überwältigen. Stattdessen müssen Sie dem Schüler helfen, sich darauf zu konzentrieren, die am einfachsten zu korrigierenden Fehler zu beheben und einige der grundlegenderen Fehler zu beheben, auch wenn dies bedeutet, dass er nicht auf den Rest aller seiner Fehler eingeht.

  Bei aufeinanderfolgenden Codeüberprüfungen können Sie dann auf die Verbesserungen aufmerksam machen, die er im Laufe der Zeit vorgenommen hat, und langsam auf die anderen Arten von Fehlern eingehen, die er möglicherweise noch macht.

Die Situation ist nicht schlecht, es ist gut. Sobald Sie sich mit dieser Tatsache vertraut gemacht haben, wird das Gespräch viel einfacher.

• Das Projekt wurde pünktlich abgeschlossen.

• Sie haben die Zeit und das Fachwissen, um das Projekt weiter zu verbessern, das bereits das tut, was es tun soll.

In der Softwareentwicklung ist es völlig selbstverständlich, Architekturen zu haben, die nicht optimal sind und um sie zu verbessern.

Bei Stilproblemen wie Namenskonventionen folgen die Leute ihnen normalerweise, sobald sie davon wissen. Erkläre sie einfach einmal und es sollte ihm gut gehen. Überprüfen Sie ihn trotzdem.

Ich würde mich nicht zu sehr auf Ihre aktuellen Erfahrungen mit ihrem Code konzentrieren.

Was meiner Meinung nach für alle Junior-Entwickler am besten funktioniert, ist die enge Zusammenarbeit mit mittelständischen und Senior-Entwicklern. Das ist vielleicht nicht immer möglich.

Aber das Unternehmen sollte mindestens regelmäßig wöchentliche Einzelgespräche zwischen Nachwuchsentwicklern und mittelständischen oder noch besseren Nachwuchsentwicklern führen. Das Thema dieses Einzelgesprächs kann alles sein, woran der Junior-Entwickler interessiert ist:

Der Schlüssel ist :

• Das Meeting ist eins zu eins. Dadurch kann der Junior alles fragen, ohne sich zu schämen, dass er etwas Offensichtliches vor anderen fragen könnte.
• Der Junior leitet das Meeting. Es ist an der Zeit, alles zu fragen.
• Das Meeting findet nicht mit ihrem Manager statt, und es geht nicht um ihre Leistung. Es ist mit einem Senior, der an einer Ausbildung interessiert ist.

Durch die Verwendung der Anführungszeichen in "1: 1 Post-Mortem 'Code Review'" gehe ich davon aus, dass dies ein informeller Prozess ist, den Sie nach Ihren Wünschen gestalten können. In diesem Fall würde ich empfehlen:

Anstatt mit dem Code des Junior-Entwicklers zu beginnen, beginnen Sie von vorne.

Dies hat in meiner Meinung die folgenden Vorteile :

• Es fühlt sich nicht so an, als würde etwas "auseinandergerissen", weil dies nicht der Fall ist.
• Sie können die von Ihnen gewünschten bewährten Methoden vollständiger demonstrieren Der Junior-Entwickler muss lernen.
• Für die Teile der Programmierung, die der Junior-Entwickler gut gemacht hat, können Sie sagen: "Und jetzt machen wir diesen Teil genau so, wie Sie es beim ersten Mal getan haben." Das wird sich wie Positives anfühlen, das in die gemeinsame Code-Erstellung eingestreut ist (während es sich in einer "Zerreißen" -Sitzung wie Neutrale anfühlt, die sich in die Kritik einmischen).

Nebenbei bemerkt, Sie sind es in der Tat versuchen, diesen Entwickler zu betreuen und Fähigkeiten zu installieren, von denen das Team in Zukunft profitieren wird. Eine dieser Fähigkeiten besteht darin, aus dem Feedback zu lernen und dieses Lernen auch in Zukunft aufrechtzuerhalten. In diesem Zusammenhang:

Führen Sie sie explizit an, wie Sie während einer Feedback-Sitzung Notizen machen. Dies ist eine Fähigkeit, die genauso bewusst gelernt werden kann wie jede andere Fähigkeit.

Natürlich möchten Sie das Meeting so gestalten, dass Sie sich vom Junior-Entwickler einkaufen lassen. Es sollte vermutlich ausreichen, ehrlich zu sein, dass Ihr Ziel darin besteht, ihnen zu helfen, ihre Fähigkeiten so zu verbessern, dass sie zufriedenstellend sind und für die sie anerkannt werden. Eine Rahmungstechnik, die Sie verwenden können, ist:

Sprechen Sie immer über Fähigkeiten in einer Wachstumsphilosophie - das heißt, Fähigkeiten sind etwas, das mit der Zeit mit Übung, Anstrengung und bewusster Selbsteinschätzung besser wird. Das Gegenteil wäre ein Problem Denkweise: Programmieren ist etwas, was Menschen entweder tun können oder nicht, wenn sie in die Tür kommen. Die Kombination eines Rahmens mit fester Denkweise und der Bewältigung der eigenen Fehler ist typischerweise das, was Abwehrbereitschaft und Engstirnigkeit auslöst. In einem wachstumsorientierten Rahmen wird es jedoch leichter als goldene Gelegenheit gesehen, sich den eigenen Fehlern zu stellen.

Schließlich als allgemeine Regel:

Klar kommunizierte Erwartungen ist ein großer Teil jedes Prozesses, an dem mehr als eine Person beteiligt ist.

Paarung

Anstelle einer Codeüberprüfung würde ich anbieten, stattdessen Paarprogrammierung mit ihm durchzuführen. Es spielt keine Rolle, ob es sich um Ihr oder sein Projekt handelt, aber es kann für einige von beiden hilfreich sein. Wenn er tippt und Sie bemerken, dass etwas verbessert werden kann, stellen Sie einfach sanfte Leitfragen wie: "Glauben Sie, dass es eine Möglichkeit gibt, dies zu verbessern?" Lassen Sie ihn einige Optionen durcharbeiten und verwenden Sie dann Hinweise, um ihn zu Ihrer Lösung zu führen. Versuchen Sie jedoch, jede von ihm angebotene Option zu analysieren, um die Gründe und Vor- und Nachteile zu erläutern. Schließlich sind einige Optionen besser als andere, ohne die beste Option zu sein, und es ist wichtig, die Gründe zu verstehen. Wenn er eine gute Antwort gibt oder Sie mit seinem Wissen überrascht, loben Sie dies, damit er während des Pairings einige Belohnungen erhält.

Stellen Sie beim Tippen sicher, dass er Fragen stellt, wenn Sie etwas Überraschendes oder Anderes tun als wie du es tun würdest. Wenn Sie wissen, dass Sie etwas tun werden, das sich davon unterscheidet, wie er das ähnliche Problem in seinem Code gelöst hat, halten Sie inne und fragen Sie ihn nach Vorschlägen, wobei Sie die Alternativen durchgehen.

Auch die wichtigsten Konventionen sind hoffentlich vom Team geübt und gefördert. In diesem Fall sollten Sie in der Lage sein, Code zu finden, den keiner von Ihnen geschrieben hat und der die Punkte veranschaulicht, die Sie ansprechen möchten. Finden Sie einige Beispiele und diskutieren Sie, damit er sehen kann, dass das Lesen von vorhandenem Code ein guter Weg ist, um zu lernen, und dass er aus vorhandenem Code lernen sollte. Lassen Sie ihn wissen, dass das Kopieren von Code style und Mustern eine Tugend ist, die er üben sollte, bis er mehr Erfahrung hat. Das bedeutet natürlich, dass er auch einige schlechte Codegewohnheiten kopieren wird, aber das ist der Preis für das Lernen.

Sokratische Methode

Im Allgemeinen lernen Menschen besser, wenn sie das Gefühl haben, selbst zur Lösung gekommen zu sein, insbesondere wenn sie eine "Eureka!" Moment. Anstatt zu sagen: "Du solltest X machen. Es ist am besten." X? Was ist mit diesem Szenario? Welche Lösung ist Ihrer Meinung nach besser? " Wenn Sie also Leitfragen stellen, können Sie den Status Quo in Frage stellen und Ihren Mitarbeiter auf einen aufgeklärteren Weg führen. Manchmal müssen Sie nur einige reale Szenarien anbieten, die veranschaulichen, warum Y besser als X ist, auch wenn Sie keine Codebeispiele zur Hand haben. Aber wenn ich jemanden an den Punkt bringen kann, an dem sie das Prinzip sagen, auf das ich mich einlasse, finde ich, dass es viel besser bleibt, weil sie über ihre eigenen Antworten und Schlussfolgerungen zu diesem Punkt gekommen sind, was bedeutet Sie stimmen mit dem Prinzip überein.

Testen

Eines der drei Dinge, von denen kein Softwareentwickler genug tut, ist das Testen. Höchstwahrscheinlich ist Ihr Junior-Partner kein Experte für Unit-Tests. Vielleicht sind Sie auch kein Experte. In beiden Fällen ist es eine hervorragende Möglichkeit, die Vor- und Nachteile einer bestimmten Technik aufzuzeigen, wenn Sie viel Zeit damit verbringen, Komponententests zu schreiben und sie zum Üben von Code zu verwenden. Sie haben vorgefertigte minimale Testfälle, die einfach angepasst werden können, um verschiedene Szenarien zu emulieren. Insbesondere bei Logikfehlern hilft es enorm, seinen Code robuster zu machen, wenn gezeigt wird, wie gute Randbedingungen für Testfälle identifiziert werden können, und wenn alle Codepfade ausgeführt werden. Sie können auch zeigen, wie das Ausführen von Komponententests zur Eingrenzung von Problemen beiträgt, indem Sie sich auf einige Methoden verlassen und andere verdächtig machen. Dies ist oft eine einfachere Teilung und Eroberung, als den Code mit Kommentaren zu halbieren.

Der wichtige Teil ist, dass all diese Dinge gleichzeitig gleichzeitig viel effektiver sind als eine Vorlesung, in der ein Großteil der Informationen "verloren" geht, weil Ihr Schüler keine Notizen gemacht hat . Wenn Sie ein neues Konzept eingeführt haben, geben Sie Ihrem Partner die Möglichkeit, es anzuwenden, damit Sie Anleitungen und Feedback zu seiner Anwendung geben können. Versuchen Sie dies sowohl kurz nach dem Unterricht als auch viel später, um die Aufbewahrung zu überprüfen. Das Schreiben von Code als Paar bestätigt, dass Sie im selben Team sind und auf dieselben Ziele hinarbeiten und dass es bei dem Prozess um Lernen und nicht um Urteilsvermögen geht. Ich vermute, dass Sie den Junior sehr schnell ausbilden und Ihre eigenen Führungs- und Mentoringfähigkeiten aufbauen werden, was immer eine schöne Leistung ist, die Sie mit dem Chef teilen können.

Beim Erlernen des Codierens geht es darum, es zu schreiben oder zumindest zu beobachten, wie jemand anderes es schreibt. Daher denke ich, dass es hilfreich wäre, wenn er sehen würde, was Sie auf einem Bildschirm tun (vorzugsweise in einer IDE, die er bevorzugt oder mit der er vertraut ist, auch wenn Sie etwas anderes verwenden), damit er sehen kann, wie der Prozess besser aussieht. Lassen Sie uns einige Beispiele diskutieren:

Hauptprobleme in der Logik

Mit anderen Worten, der Code tut nicht das, was er sollte; Es hat einen Fehler. Erklären Sie ihm einen, wie Sie ihn entdeckt haben und welcher Code dies korrigieren würde. Aber wie machst du das alles? Nun ...

Unwissen darüber, wie ein Problem auf die Grundursache zurückgeführt werden kann

Zeigen Sie ihm im Zusammenhang mit dem vorherigen Punkt, wie Sie es tun würden Diagnose und Behebung der oben genannten Fehler.

undurchsichtige Namenskonventionen

Machen Sie dies nicht nur , indem Sie sagen: "Wir wollen Dinge, die so benannt sind". Zeigen Sie die besten Möglichkeiten zum Ändern der Namen. Die IDE macht das einfacher; Je nachdem, was für die Erkennung eingerichtet ist, werden möglicherweise auch bestimmte Änderungen vorgeschlagen oder sogar automatisiert. Wenn Sie solche Dinge eingerichtet haben, er es aber nicht tut, ändern Sie diese Situation für ihn oder zeigen Sie ihm, wie es geht.

Beachten Sie, dass es bei diesem Ansatz nicht nur darum geht, einschüchternd lange Notizen einzubringen, an die Sie geschrieben haben Sagen Sie: "Bitte denken Sie an all diese Regeln." Es geht darum, ihm zu zeigen, wie man das macht, was er tun soll. Es lehrt den savoir-faire.

[Ich] hatte nicht genug Zeit, um das "Warum" für alles zu besprechen, was ich & empfohlen hatte, ihm zu helfen.

Ich denke, was ich vorgeschlagen habe, hilft auch bei diesem Zeitproblem. Ich muss niemandem mit Ihrer Erfahrung sagen, um wie viel sich der Code vor den Augen eines Betrachters mit ein paar Minuten dieser Tricks verbessern kann. Er könnte es jedoch als angenehme Überraschung empfinden, je nachdem, wie viele Seile ihm in den letzten Monaten gezeigt wurden.

Er spricht sehr leise & scheint sich manchmal die Dinge zu Herzen zu nehmen.

@ PlayerOnes ausgezeichnete Antwort betonte die Notwendigkeit, "dies muss so verbessert werden" zu einer unpersönlichen Beobachtung zu machen. Dies lässt sich leicht in die obige Strategie integrieren. Der Satz "Lassen Sie mich Ihnen zeigen, wie es geht" ist mehr oder weniger persönlich, je nachdem, wie er gesagt wird, aber der edelste Geist dessen, was er sagt, ist der springende Punkt dieser Übung.

Er wird von unserem Chef eingehend auf seine Leistung überprüft.

Wenn ihn dies beunruhigt, kann dies seine Zustimmung dazu motivieren, Ihrer Demonstration zu folgen. Wenn Sie nicht wissen, dass er sich darüber Sorgen macht, müssen Sie es nicht ansprechen oder den oben genannten Ansatz darauf basierend moderieren. Ich bin sicher, wenn Sie meinem Vorschlag folgen würden, würden Sie es sowieso auf angstmindernde Weise tun.

Er scheint während der Überprüfungen / Schulungen keine guten Notizen zu machen, und er auch ist nicht sehr proaktiv beim Stellen von Fragen, wenn er bei Aufgaben hängen bleibt. Daher bin ich mir nicht so sicher, wie sehr diese Codeüberprüfung wirklich in seinem Gehirn "stecken" bleibt.

Das ist ein klarer Grund, warum das Auslesen Ihrer Notizen ungeachtet dessen die Erfolgschancen verringert wie gemein oder nett du damit bist. Ich kann nicht beweisen, dass es in Aktion funktioniert, da etwas, das passiert, wenn wir mit dem lebenden, atmenden Tier interagieren, das der Code ist, besser funktionieren würde. Aber die Idee, dass es mit meiner Erfahrung vereinbar wäre. Bitten Sie ihn, Sie zu bitten, eine Pause einzulegen oder zu verlangsamen, wenn er etwas aufschreiben möchte, das er für besonders gerechtfertigt hält.

Was kann ich noch tun, um das Problem zu mildern? Schlag, wenn ich durch die Wäscheliste der Dinge gehe, die er im Code falsch gemacht hat?

Sie benötigen keine Wäscheliste - jedenfalls nicht alle in einer Sitzung. Der von ihm eingereichte Code ist nicht ganz richtig. Das ist in Ordnung: Der Code, an dem er überhaupt arbeiten musste, war auch nicht ganz richtig, zumindest nicht für moderne Anforderungen. Die Tatsache, dass Sie in dieser persönlichen Demonstration von "seinem" Code ausgehen, ist nebensächlich. Es zeigt ihm, wie er jeden Code adressiert, auf den er stößt. Möglicherweise müssen Sie dies mehrmals tun, je nachdem, wie viele Dinge er aufgreifen muss. Sie können ein paar Tage nach der ersten Sitzung abschätzen, was angesichts der Bedürfnisse von ihm und dem Team für beide Seiten akzeptabel wäre. Aber bringen Sie ihm die wichtigsten Strategien bei, und die Probleme, die dieses Mal auftraten, werden sich auf lange Sicht von selbst erledigen.

Welche Methoden gibt es, um die Wirkung dieser Schulung / Überprüfung zu steigern? ... Ich glaube nicht, dass er Erfolg haben wird, wenn er sich nicht wirklich bemüht, die Best Practices der &-Methoden zu erlernen, die alle anderen im Team anwenden.

Ich überlasse es Ihnen Um zu entscheiden, inwieweit Sie ihn einladen sollten, in Momenten, in denen Sie hoffen, dass er anhand eines frühen Teils der Demonstration ableiten kann, was er tun soll, das Steuer zu übernehmen. Abgesehen davon habe ich einen Vorschlag, der von der allgemeinen Prämisse dieser Antwort getrennt ist: Empfehlen Sie ihm einen guten Leitfaden zum Lesen (oder sehen Sie ihn sich an, wenn Sie wirklich gutes Videomaterial kennen). Eine Anleitung für den Moment oder vielleicht zwei oder drei sehr kurze. Wenn es sich um eine Anleitung handelt, die Ihnen geholfen hat, werden weitere Leitfäden weniger Renditen erzielen. Überlasten Sie ihn also nicht oder scheinen Sie es zu tun.

Es gibt keine Option für automatisierte Codeüberprüfungen, bevor Sie den Code weitergeben zur "Produktion". Dies macht es schwieriger, die oben beschriebenen Arten von Problemen zu erfassen.

OK, Zeit für eine weitere Idee. Sagen Sie ihm, dass er Sie bitten kann, sich seinen Code anzusehen, bevor er ihn einreicht, um zu sehen, was Sie davon halten. Wenn Sie können, führen Sie solche Codeüberprüfungen durch, auch wenn Sie einen Stuhl überziehen müssen, anstatt etwas zu verwenden, das Sie in diesem Projekt nicht haben können, was im Team häufiger vorkommt. Es geht nicht nur darum, ihn nicht herauszuheben. Die letzte Firma, für die ich gearbeitet habe, war der Meinung, dass der gesamte Code zwei Nicht-Autoren vor einem Push überprüfen sollte. Vielleicht könnte er einer von zwei Rezensenten für den Code von jemandem sein, sogar für Ihren Code! All dies sollte natürlich nur schrittweise eingeführt werden, da er möglicherweise nicht über die richtigen Fähigkeiten verfügt oder sich dieser nicht sicher ist, um sofort ein solcher Rezensent zu sein.

Wenn es um größere Korrekturen an der Arbeit eines anderen geht, Probleme, die das Ego betreffen, ist es sehr schwierig, die Partei zu finden, die die Hilfe benötigt, um die Korrektur zu akzeptieren, und je schlimmer die Fehler, desto schwieriger ist es.

Der Weg, jemanden dazu zu bringen, Veränderungen zu akzeptieren, besteht darin, ihn dazu zu bringen, sie selbst zu realisieren. Sie können sagen, dass Sie den Code überprüfen und den Programmierer bitten müssen, ihn zu durchlaufen, aber versuchen Sie, alles als Frage zu tun. Versuchen Sie, den Junior-Programmierer dazu zu bringen, es selbst herauszufinden. Beispiel:

  int xj6b7 = 99.2;  

Können Sie feststellen, dass an dieser Deklaration etwas nicht stimmt? Können Sie erkennen, warum ein anderer Programmierer möglicherweise Probleme mit dem Verständnis hat? Können Sie ein Problem mit der Konstante 99.2 erkennen? Er wird es nicht unbedingt finden. Sie können dieses Problem jeweils einzeln ausführen. Sie können vernünftigerweise darauf bestehen, dass der Junior sich daran erinnert, Notizen zu machen, damit er zurückgehen und es erneut tun kann.

  x = x / 2; // x durch 2 teilen  

Kannst du mir sagen, warum du diesen Kommentar geschrieben hast? Wem versuchst du diesen Code zu erklären?

Und ja, es ist besser um es aufzubrechen und nicht zu versuchen, jedes Problem mit dem Code dieser Person in einer Sitzung zu behandeln. Geben Sie ihnen eine einfachere Aufgabe, feinkörniger und lassen Sie sie Fähigkeiten in kleineren Schritten entwickeln. Es war ein Fehler, ihnen offensichtlich einen so großen Teil zu geben.

Wie erfolgreich dies ist, hängt von der Persönlichkeit des Lernenden ab (und von meinem Talent, es anzuwenden). In solchen Fällen versuche ich, Fragen zu stellen , anstatt Erklärungen abzugeben.

Beispiele:

• „Was macht dieses Unterprogramm? …… Oh, dann könnten wir es vielleicht so nennen, anstatt es „M400“ zu nennen.
• „Macht diese Schleife etwas anderes als diese? Oh, könnten sie dann in ein Unterprogramm einbezogen werden? “

Es gibt repräsentative 2 Zitate, die mir in meiner Zeit als Entwickler begegnet sind und an die ich mich wirklich gewöhnt habe und die ich gerne wiederhole, wenn ich die hier behandelten Probleme diskutiere. Diese Situation muss beide respektvoll angehen - Ihr Coaching ist ein wertvolles Geschenk für jemanden, der neu in der Branche ist, aber die Art und Weise, wie Sie dieses Geschenk präsentieren, wird einen großen Unterschied in der Bewertung bewirken. P. >

Selbstbewusstsein und Bitte um Hilfe im Kontext eines Teams und des größeren Ökosystems:
"Der durchschnittliche Entwickler hat das gleiche Ego wie der durchschnittliche Jet-Pilot."

"Ich werde auch meinen ersten Job außerhalb des College nie vergessen. (Auch wenn es 'am College' war.)"

Hier ist mein Vorschlag:

"Eines haben Sie beide objektiv gemeinsam: den Quellcode, der erstellt wurde."

Und außerdem:

"Der Prozess , der führte (" Lassen Sie uns beide zwinkern, als ob er anonym wäre ... ") Entwickler-X zur Erstellung des Quellcodes-Y als Antwort auf Anforderung-Z. "

Sprechen Sie über das Arbeitsprodukt ... den Quellcode .. . und der Arbeitsprozess. Nicht über den Arbeiter. Machen Sie absolut (!) klar, dass die Beschäftigung der Person nicht gefährdet ist ... "Wenn wir nicht gedacht hätten, dass Sie darin gut sind, hätten wir Sie nie eingestellt." Machen Sie deutlich, dass das Unternehmen fest entschlossen ist, dieser Person jetzt beim Wachstum zu helfen.

Vollständige Offenlegung: "Das erste Computerprogramm, das ich jemals geschrieben habe [in BASIC] war acht Zeilen lang, brauchte sechs Monate, um [in den späten 1970er Jahren] zu schreiben, und hatte einen Fehler darin. "

" Die Entwicklung von Computersoftware ist eine verdammt schwierige Sache " und wir müssen immer klarstellen, dass wir das verstehen. "Ja, wir wissen, dass es schwer ist, und ... wir haben Ihren Rücken."

Stellen Sie sicher, dass er einen Stift und Papier zur Codeüberprüfung mitbringt.

Bitten Sie ihn vor der Codeüberprüfung, Stift und Papier mitzubringen, und erwarten Sie, dass er sich Notizen macht. Wenn er ohne sie auftaucht, weisen Sie ihn an, zu seinem Schreibtisch zurückzukehren, sie abzuholen und dann zurückzukehren, sobald er dies tut. Starten Sie es erst, wenn er die benötigten Materialien hat. Stellen Sie sicher, dass Sie während der Überprüfung nach jedem Punkt eine Pause einlegen, damit er entsprechende Notizen machen kann.

Wenn er bereit ist, zerreißen Sie seinen Code und erklären Sie, warum er schlecht ist und warum Ihr Weg besser ist. Halten Sie sich nur an die Fakten; spekuliere nicht über seine Motive. Wenn er etwas gut gemacht hat, beginnen und beenden Sie Ihre Codeüberprüfung mit diesen Bereichen - der "Sandwich-Technik" für Feedback. Wenn er emotional oder defensiv wird, halten Sie einen Moment inne und stellen Sie sicher, dass ihm klar ist, dass Sie ihn nicht angreifen, sondern versuchen, ihm zu helfen. Er kann sich nicht verbessern, wenn er schließlich nicht versteht, in welchen Bereichen er nicht gut abschneidet.

Teilen Sie zwei Dinge auf:

• die Namenskonventionen des formalen Teils
  2. nicht verwendeter Code
  3. Codeformatierung
  4. Stil der Kommentare
  ol>
• Der Teil Erfahrung / Logik / Architektur

Der formale Teil, den Sie mit "Entschuldigung" ansprechen müssen , ich bin dein Chef / Projektleiter ", mach es. Wenn Sie dies nicht tun, hat dies disziplinarische Konsequenzen. Sagen Sie mir, wie viel Zeit Sie benötigen, und wir werden das planen.

Bitten Sie ihn / sie im Übrigen, Ihnen eine Skizze oder einen Überblick darüber zu zeigen, wie ein neuer Code implementiert wird, bevor Sie ihn starten und mit ihm diskutieren Sie. Erklären Sie bestimmte Dinge vorerst für verboten (das habe ich in einem Projekt getan, als es darum ging, die Datenstruktur zu berühren).