Wie gehe ich vor, um Code von einem weniger erfahrenen Programmierer zu reparieren?

Ein kleiner Hintergrund: Ich bin einer von zwei Programmierern für unsere Abteilung mit 10 Mitarbeitern (der Rest sind Künstler und Management). Wir beide schreiben alles, was nötig ist, um einen reibungslosen Ablauf zu gewährleisten, und entwickeln alle anstehenden Projekte. Ich programmiere seit ungefähr 4 Jahren, wo dies sein erster "richtiger" Job ist (wie er es ausdrückt). In der Regel arbeiten wir zu jedem Zeitpunkt an unterschiedlichen Projekten.

Vor ein paar Monaten habe ich eine (keineswegs perfekte) Reihe von Klassen entwickelt, die für ein späteres Projekt verwendet werden sollten. Ein großer Teil dieses Projekts wurde (aus Abrechnungsgründen) an ihn delegiert, um eine GUI-Oberfläche zu entwerfen und zu programmieren. Da er neu war, half ich ein bisschen beim Entwerfen und bat um Hilfe, wenn er sie für den Rest brauchte. Er hat das Interface vor ein paar Wochen fertiggestellt, was er demonstrieren wollte, um zu zeigen, dass es funktionierte, wenn auch etwas langsam.

Der nächste Teil des Projekts, an dem ich arbeite , hat begonnen . Ich habe die Benutzeroberfläche geöffnet, um mit den nächsten Schritten zu beginnen, und bin sofort auf Probleme gestoßen (ein wenig langsam war ein wenig Untertreibung, Fehler bei allgemeinen Aktionen usw.). Ich habe den Code nach ein paar Problemen durchgesehen und O(n^n)bei Aufrufen festgestellt, dass es sich dabei um O(n)Annahmen ohne Fehlerprüfung (in Python), Verweise auf die dem ursprünglichen Code hinzugefügte GUI usw. handeln sollte.

Jetzt möchte ich ihm auf jeden Fall beibringen, was falsch war und wie man es repariert, aber er ist bereits zu seinem nächsten Projekt übergegangen, und das war vor ein paar Wochen. Ich fürchte, ich sage "Geh zurück und mach es richtig!" (mit hilfe natürlich) ist zu hart und wir haben in der zwischenzeit noch andere projekte zu erledigen. Sollte ich den Code jetzt einfach selbst reparieren und versuchen, die Dinge in der Zukunft einzufangen?

Klingt so, als ob die Einführung einer Codeüberprüfungsrichtlinie auf mehreren Ebenen vorteilhaft sein könnte. Einige unmittelbare Vorteile:

• Sie können die Qualität seines Codes direkt beeinflussen, bevor der Code festgeschrieben wird, wodurch die Qualität der Codebasis hoch bleibt
• Hält Sie davon ab, ähnliche Fehler zu machen, die andere Augen fangen könnten
• In Ermangelung von Kodierungsrichtlinien führen Überprüfungen natürlich zu einer Konsistenz des Kodierungsstils
• Wissen teilen. Wenn nur zwei von euch sind und einer von einem Bus angefahren wird ...

Wenn Sie nun damit beginnen, seinen Code zu bereinigen, verwenden Sie dies als Unterrichtsübung, wenn Sie eine Überprüfung dieses Codes anstreben. Du wirst deine Sachen überprüfen lassen, und er wird vielleicht lernen, wie man es beim nächsten Mal besser macht.

Korrigieren Sie niemals ihren Code, sonst lernen sie nichts anderes, als wenn sie Fehler machen, werden sie abgefangen und repariert. Die Aufgabe wird erst erledigt, wenn sie erledigt ist . Ich hatte wirklich Glück, als ich anfing, professionell zu sein, und mein direkter Vorgesetzter überprüfte alles, was ich getan hatte, und wenn es eine bessere Lösung gab oder ich einen dummen Fehler gemacht hatte, sagte er mir, was bedeutete, dass meine Fähigkeiten besser wurden, was bedeutete, dass ich mich schneller verbesserte und weiterentwickelte eine härtere Haut.

Wenn Sie es abrutschen lassen, können Sie schlechte Angewohnheiten entwickeln. Wenn Sie es jetzt korrigieren, können Sie besser mit Kritik umgehen.

Können wir daraus schließen, dass das Projekt "funktioniert" und in einem angemessenen Zeitraum abgeschlossen wurde (wenn auch mit einigen ungeheuren, aber behebbaren Designproblemen)? Wenn ja, ist es in einem viel besseren Zustand als viele Projekte, die ich im Laufe der Jahre gesehen habe.

Ich denke, dass mehr Kommunikation Ihrem Team helfen würde - und dies könnte durch regelmäßige Codeüberprüfung geschehen.

Es ist gut, dass Sie empfindlich dafür sind, "zu hart" zu sein, und ich denke, Sie werden bedenken, dass die Codeüberprüfung kein demoralisierendes Hot-Seat-Erlebnis sein muss, bei dem die Junior-Leute gegrillt und hinterfragt werden. Es kann auch eine Möglichkeit für leitende Entwickler sein, bewährte Praktiken zu demonstrieren und Vertrauen ineinander zu gewinnen, indem sie auch bei "Fehlern" höflich und freundlich sind.

Die Leute lernen gut, wenn sie sehen, wie wirklich gutes Zeug aussieht. Dies ist besser, als systematisch auf jeden kleinen Fehler hinzuweisen. Das O (n ^ n) sollte jedoch vorsichtig und konstruktiv herausgestellt werden.

Teilen Sie Ihr Wissen.

Ich würde ihm Hilfe bei seinem neuen Projekt anbieten, im Austausch für etwas Unterricht von einem Senioren bis zu einem Junioren.

Warum nicht bei beiden Projekten die Programmierung koppeln?