it-swarm.com.de

Wie gehe ich mit "fast gutem" Code eines Junior-Entwicklers um?

Ich habe eine Frage zum Teammanagement. Im Moment habe ich es mit einem Junior-Entwickler zu tun, der remote von einer Codierungsfabrik aus arbeitet. Der Typ ist offen für Kritik und bereit zu lernen, aber ich habe einige Zweifel, wie viel ich ein paar Sachen pushen soll.

Gerade jetzt, wenn etwas klar und offensichtlich ist, ein Verstoß gegen bewährte Praktiken: wie ein Verstoß gegen SRP, Gottes Objekte, nicht aussagekräftige Namen für Methoden oder Variablen; Ich weise darauf hin, was er reparieren muss, und versuche zu erklären, warum es falsch ist.

Meine Frage ist: Wann höre ich auf? Im Moment, wenn es einige geringfügige Verstöße gegen den Codierungsstil gibt, wie z. B. Variablennamen in der falschen Sprache (vorheriges Team hat Spanisch und Englisch gemischt und ich versuche, das zu beheben), oder einige kleinere strukturelle Probleme, lasse ich los und behebe es, wenn Ich habe Freizeit oder muss die problematische Klasse ändern. Ich bin der Meinung, dass dies gut für die Moral des Teams ist, daher drücke ich den Code nicht ständig zurück, was für einen Anfänger wie kleine Details erscheinen könnte, was ziemlich frustrierend sein kann, aber ich mache mir auch Sorgen, dass zu "weich" den Kerl daran hindern könnte vom Lernen, wie man ein paar Sachen macht.

Wie kann ich die Grenze zwischen dem Unterrichten des Mannes und dem Nichtausbrennen mit ständiger Kritik ausgleichen? Für einen Junior kann es frustrierend sein, wenn Sie ihm sagen, dass er Dinge wiederholen soll, die für seine Augen funktionieren.

100
Zalomon

Wenn Sie der Meinung sind, dass der Code vor dem Zusammenführen behoben werden sollte, geben Sie Kommentare ab. Am besten mit "Warum", damit der Entwickler lernen kann.

Denken Sie daran, dass Code viel häufiger gelesen als geschrieben wird. Dinge, die "geringfügig" erscheinen, können also tatsächlich wirklich wichtig sein (z. B. Variablennamen).

Wenn Sie jedoch Kommentare abgeben, die langweilig erscheinen, sollten Sie Folgendes berücksichtigen:

  • Sollte Ihr CI-Prozess diese abfangen?
  • Haben Sie einen klaren "Entwicklerleitfaden" zum Nachschlagen (oder ist alles in Ihrem Kopf dokumentiert)?
  • Tragen diese Kommentare tatsächlich zur Codequalität bei?

Viele Menschen opfern die Produktivität am Altar des Prozesses oder der Perfektion. Sei vorsichtig, dass du das nicht tust.

Versuchen Sie, Ihren Kollegen möglichst persönlich zu besuchen. Oder verwenden Sie Videoanrufe. Der Aufbau einer Beziehung erleichtert die Verwaltung von Kritik (auch von Codeüberprüfungen).

Wenn Sie feststellen, dass ein Codeteil zu viele Probleme aufweist, fordern Sie die Überprüfung kleinerer Codeteile an. Inkrementelle Änderungen vermeiden eher einige der bedeutenderen Entwurfsprobleme, da sie per Definition kleiner sind.

Aber unbedingt nicht Sachen zusammenführen und dann zurückgehen und es reparieren. Dies ist passiv aggressiv und wenn der Entwickler feststellt, dass Sie dies tun, werden Sie seine Moral töten.

85
enderland

Behalten Sie die Kritik am Code und nicht am Verfasser.

Jede produzierte Arbeit ist mit einer emotionalen Bindung verbunden. Erwägen Sie, dies zu vereinfachen, indem Sie den Code so weit wie möglich vom Writer trennen. Die Qualität des Codes sollte konsequent als gemeinsames Ziel festgelegt werden, dem Sie beide gemeinsam gegenüberstehen, und nicht als Reibungspunkt zwischen Ihnen.

Eine Möglichkeit, dies zu erreichen, besteht darin, Ihre Worte mit Bedacht auszuwählen. Obwohl MINT-Individuen sich gerne als sehr logisch betrachten, sind Emotionen ein Teil der menschlichen Natur. Das verwendete Wort kann der Unterschied zwischen verletzten oder verschonten Gefühlen sein. Die Aussage "Dieser Funktionsname würde den Konventionen besser entsprechen, wenn er auf Englisch wäre" ist vorzuziehen gegenüber "Sie haben diesen Funktionsnamen falsch geschrieben und er sollte auf Englisch sein." Während das letztere noch zahm ist und allein in Ordnung erscheint, werden seine Fehler im Vergleich zum ersteren offensichtlich - wenn Sie vorbereiten, was Sie persönlich oder per E-Mail sagen möchten, prüfen Sie, ob Ihr Kontext, Ihre Wörter und Ihr Fokus auf dem Ausgaben statt der Person.

Körpersprache

Während Wörter wichtig sind, ist die meiste Kommunikation nonverbal. Achten Sie auf die Körpersprache, auch auf scheinbar unbedeutende Feinheiten wie Orientierung, z. Viele Senior-Junior-Interaktionen finden von Angesicht zu Angesicht statt, doch ein Side-by-Side-Ansatz wäre für Ihr gewünschtes Ergebnis viel förderlicher.

Geben Sie ehrliches positives Feedback

Eine Vielzahl von Studien zeigt, dass Informationen schneller gelernt und besser gespeichert werden, wenn wir gutes Verhalten belohnen, anstatt schlechtes zu bestrafen. Manchmal nur bemerkt, dass die Leistung durch einen einfachen "guten Job" oder einen spezifischeren "Ich habe in letzter Zeit bemerkt, dass Ihr Stil unseren Standards zu einem Abschlag passt, großartige Arbeit!" Verbessert wurde. Selbst wenn Sie diese Anerkennung der Verbesserung ergänzen, indem Sie sie wiederum andere Personen zu den von ihnen geänderten Themen beraten lassen, kann dies den Unterschied für Ihren Junior-Entwickler und seine Arbeit ausmachen.

19
Legato

Basierend auf Ihrer Beschreibung würde ich es bei belassen: "Das ist gut. Es gibt ein paar Dinge, die ich anders gemacht hätte, aber sie sind nicht sehr wichtig."

Wie Sie zu begreifen scheinen, hat Kritik Kosten und wenn Sie viel Zeit damit verbringen, Details zu verfälschen, wird dies zu einem moralischen Problem. Im Idealfall werden alle Codierungsstandards automatisch überprüft und Sie können nur erstellen, wenn Sie sie befolgen. Dies spart viel Zeit und ermöglicht es Ihnen, zur Sache zu kommen. Wenn Sie Ihre Kritik für „Dinge, die wichtig sind“ reservieren, hat Ihr Rat viel mehr Einfluss und Sie werden als geschätzter Mentor angesehen. Es ist wirklich wichtig, zwischen Dingen zu unterscheiden, die nicht gut sind, und Dingen, die nicht genau so sind, wie Sie es tun würden.

Ich glaube an das Konzept des lehrbaren Moments . Wenn der Entwickler über genügend geistige Fähigkeiten verfügt, fragt er möglicherweise nach den Details, was Sie anders machen würden. (S) er könnte nicht und das ist in Ordnung. Menschen werden ausgebrannt und zu Beginn einer Karriere kann es viel geistige Energie erfordern, um Dinge zu erreichen, die später einfach erscheinen.

5
JimmyJames

Ich würde in Betracht ziehen, seine Arbeit anzunehmen, wenn sie akzeptabel und nicht perfekt ist. Und dann ist die nächste Aufgabe nach einer Diskussion, sie sofort umzugestalten, indem Sie alle kleinen, aber wichtigen Änderungen vornehmen, die Sie möchten.

Wenn also die Arbeit zum ersten Mal angenommen wird, lautet Ihre Botschaft, dass sie nicht schlecht war und einige Orte sie als gut genug akzeptiert hätten - aber nicht Orte, an denen Sie als Junior-Entwickler sein möchten, der sein Handwerk richtig lernen möchte.

Sie sagen also nicht "Ich lehne Ihre Arbeit ab, weil sie nicht gut genug ist". Sie sagen (a) "Ich akzeptiere Ihre Arbeit, weil sie gut genug ist" und dann (b) "Aber ich will es besser".

5
gnasher729

Der Typ ist offen für Kritik und lernbereit, aber ich habe einige Zweifel, wie viel ich ein paar Sachen pushen soll.

Schieben Sie alles, was Sie können. Wenn der Typ lernt und es Ihre Aufgabe ist, seinen Code zu überprüfen, haben Sie beide viel zu gewinnen, wenn er gute Arbeit leistet.

Das bedeutet weniger Code, den Sie in Zukunft überprüfen müssen, und gibt Ihrem Team möglicherweise ein Einstellungsziel.

Wenn Sie sich zurückhalten, helfen Sie nicht, sondern bevormunden.

Allein die Tatsache, dass Sie Ihre Frage hier gestellt haben und gefragt haben, ob Sie zu viel tun, zeigt mir bereits, dass Sie diesen spezifischen Rat nicht benötigen, aber für andere kommt es: Denken Sie daran, dass hartes Drücken nicht bedeutet ein Idiot sein.

Mentor zu sein ist keine leichte Aufgabe. Sie müssen ihm auch etwas Platz geben, um einige Fehler zu machen und sie selbst zu korrigieren. Stellen Sie nur sicher, dass er das an einem Ort tut, der keinen wirklichen Schaden anrichtet.

5
Machado

Ziemlich offene Frage, aber hier sind ein paar Ideen.

  1. Peer Reviews (vom Junior-Entwickler)

    Der beste Weg für jemanden, den "richtigen" Weg zu lernen, ist zu sehen, wie andere es tun. Führen alle Ihre Entwickler Codeüberprüfungen durch? Es ist möglicherweise keine schlechte Idee, sie auch von Ihrem Junior-Entwickler ausführen zu lassen (obwohl Sie auch mindestens eine Überprüfung von einem Senior-Entwickler verlangen sollten). Auf diese Weise wird er gute Programmierer in Aktion sehen und feststellen, dass es Überprüfungskommentare gibt, die sich an andere Ingenieure als ihn selbst richten, was bedeutet, dass dies nicht persönlich ist.

  2. Frühes Feedback/Aufgabenüberprüfungen

    Ermöglichen Sie dem Entwickler, an seiner eigenen Aufgabenaufschlüsselung teilzunehmen. Lassen Sie ihn sein beabsichtigtes Design in den Aufgabennotizen festhalten und eine "Codeüberprüfung" ohne Änderungssatz und nur die Aufgabe einreichen. Auf diese Weise können Sie seinen Plan überprüfen, bevor er eine einzelne Codezeile geschrieben hat. Sobald seine Aufgabe überprüft wurde, kann er mit dem Codieren beginnen (danach wird er eine weitere Codeüberprüfung einreichen). Dies vermeidet die demoralisierende Situation, in der der Entwickler eine Menge Dinge geschrieben hat und Sie ihm sagen müssen, dass er sie neu schreiben soll.

4
John Wu

Wenn der Code objektiv gegen einen geschriebenen, eindeutigen Standard verstößt, sollten Sie meiner Meinung nach so lange zurückschieben, bis jedes Problem behoben ist. Sicher, es könnte für den Entwickler bei den ersten Commits etwas ärgerlich sein, aber er könnte die Richtlinien genauso gut früher als später lernen.

Wenn Sie hier und da ein paar Verstöße gegen Standards zulassen, stellen sie einen schlechten Präzedenzfall dar - siehe Theorie der kaputten Fenster . Außerdem ist es viel einfacher, sich daran zu erinnern, die Standards zu befolgen, wenn sie bereits konsistent auf die Codebasis angewendet werden. Also gewinnt wirklich jeder, einschließlich der fraglichen Junior-Entwickler.

Ich denke nicht, dass die Moral ein großes Problem ist, solange der Kodierungsstandard aufgeschrieben ist. Nur wenn es subjektiver wird "gut, [~ # ~] i [~ # ~] hätte es anders gemacht" - Gebiet, dann Sie sollte besorgt sein, da der Entwickleransatz möglicherweise genauso gültig ist.

2
JacquesB

Erwägen Sie die Einführung eines Codeüberprüfungs-Workflows, bei dem Entwickler ihre vorgeschlagenen Commits an ein Tool wie Github Pull Requests oder Phabricator Diffusion senden und eine Peer-Abmeldung erhalten, bevor sie ihre Änderungen in den gemeinsam genutzten Hauptzweig übertragen.

Auf diese Weise wird die Arbeit nicht rückwirkend kritisiert oder jemanden gebeten, das bereits Erledigte zu wiederholen, sondern nur noch nicht erledigt, bis die Peer Review bestanden ist. Das Hin und Her mit Peers ist ebenso Teil des Software-Engineering-Prozesses wie das Hin und Her mit dem Compiler.

Sie können Ihre Bedenken als Kommentare zu bestimmten Zeilen veröffentlichen und Diskussionen darüber führen. Er kann dasselbe mit Ihrem Code tun. Die Diskussion konzentriert sich weiterhin auf die spezifischen vorgeschlagenen Codeänderungen und nicht auf die Leistung oder Kompetenz einer Person im Allgemeinen.

Selbst brillante leitende Ingenieure in meinem Unternehmen sind dankbar, wenn Codeüberprüfungen Tippfehler erkennen oder sie zwingen, die Dinge klarer zu machen. Es ist völlig normal, dass Neueinstellungen mehr Iterationsrunden erfordern. Mit der Zeit beginnen Sie reflexartig, die Art von Problemen zu beheben, von denen Sie wissen, dass sie Kommentare anziehen vor Posten eines Diff. Wenn Sie beim ersten Versuch einen höheren Prozentsatz Ihrer Unterschiede akzeptieren, wissen Sie, dass Sie sich verbessern.

2
closeparen

Ich drücke den Code nicht ständig zurück, was für einen Anfänger wie kleine Details erscheinen mag, was ziemlich frustrierend sein kann, aber ich mache mir auch Sorgen, dass zu "weich" den Kerl daran hindern könnte, zu lernen, wie man einige Dinge macht.

Dies sind sowohl echte Möglichkeiten als auch berechtigte Bedenken. Fragen Sie den Entwickler, wie er sich dabei fühlt.

1
Kevin Krumwiede

Unter der Annahme, dass Sie einen Pull-Request- oder Code-Review-Workflow haben und dies anscheinend der Fall ist, würde ich empfehlen, Dinge zu notieren, die "unkritisch" oder "bevorzugt" sind.

Wenn Sie eine PR in einem ähnlichen Zustand wie den von Ihnen beschriebenen sehen, mit einigen geringfügigen stilistischen Problemen oder wenn Sie ein nicht kritisches Refactoring benötigen, hinterlassen Sie einen Kommentar, aber Sie können ihn auch gerne genehmigen. Wenn Sie etwas sagen wie "Versuchen Sie in Zukunft vielleicht, Methodennamen wie diesen zugunsten von so etwas wie deskriptivem Methodennamen zu vermeiden", wird Ihre Meinung dokumentiert, ohne dass sie gezwungen werden, sie zu ändern oder ihre Entwicklung zu blockieren.

Jetzt kennen sie Ihre Präferenz und würden hoffentlich eine solche Situation in Zukunft bemerken, wenn sie versuchen, sich zu verbessern. Es lässt auch die Tür offen, damit sie sie zu diesem Zeitpunkt tatsächlich ändern können, falls sie Ihnen zustimmen und sie als kritisch genug ansehen.

1
zak

Eine andere Idee, um mit "zu viel Kritik" umzugehen, besteht darin, von Zeit zu Zeit eine Aufgabe selbst zu erledigen und den Junior-Entwickler eine Codeüberprüfung für Sie durchführen zu lassen. Dies hat mindestens zwei Vorteile:

  • sie können sehen, wie Sie erwarten, dass Dinge getan werden.
  • in Fällen, in denen es mehrere gute Lösungen oder Variablennamen gibt, akzeptiere ich Vorschläge für unterschiedliche, aber (fast?) gleich gute Ansätze. Wenn ich meinen Code aufgrund eines Kommentars korrigiere, versuche ich den Leuten zu zeigen, dass sie respektiert werden, und die Kritik betrifft immer nur Code - unabhängig davon, wer der Autor ist.
0
BartoszKP

Ich habe es mit einem Junior-Entwickler zu tun, der remote von einer Codierungsfabrik aus arbeitet.

Dies ist leider keine ideale Situation: Ein fortgeschrittener Programmierer, der für einen unerfahrenen Programmierer zuständig ist, mit geografischer Trennung. Es ist nicht überraschend, dass es einige Spannungen gibt, aber die Ungleichheit kann gemindert werden.

Ich bin neugierig, was meinst du mit "Coding Factory"? Diese Terminologie weist für mich auf eine beunruhigende Haltung hin, die einige der von Ihnen erwähnten Managementprobleme möglicherweise verschärft.

… Verletzung von SRP, Gottobjekten, nicht aussagekräftigen Namen für Methoden oder Variablen; Ich weise darauf hin, was er reparieren muss, und versuche zu erklären, warum es falsch ist.

Ich denke, das Problem ist, dass Ihr Junior-Entwickler Code ausspuckt, ohne einen ordnungsgemäßen Entwurfsprozess durchlaufen zu haben. Dies ist ein Fehler von Ihrer Seite als Manager und leitender Entwickler, wenn es darum geht, Anleitungen zu geben und gute Softwareentwicklungsgewohnheiten zu vermitteln. Sie können verhindern, dass fehlerhafter Code überhaupt geschrieben wird, wenn Sie zuerst zusammenarbeiten, um einen Umriss zu skizzieren. Dies wäre der Kritik und Umschreibung von Code nach seiner Erstellung sowohl hinsichtlich Effizienz als auch Moral vorzuziehen.

Sie müssen wahrscheinlich Ihren Workflow neu anpassen. Es hört sich so an, als würden Sie derzeit erwarten, dass er Ihnen Produkte liefert. Was Sie brauchen, ist eine engere Zusammenarbeit, damit Sie bei jedem Entwicklungsschritt eine Anleitung geben können. Sprechen Sie über das Design und die Benutzeroberfläche, bevor Sie mit dem Codieren beginnen. Führen Sie während der Codierung häufigere Checkpoints durch, um Probleme früher zu erkennen. Versuchen Sie nach Möglichkeit die Paarprogrammierung über die Bildschirmfreigabe mit einem Audiokanal.

All dies erfordert mehr Aufwand von Ihrer Seite, aber es wird sich angesichts der problematischen Beziehung, die Sie derzeit haben, wahrscheinlich lohnen.

0
200_success