Wie sollte Code "Goal Tending" von einem Entwicklungsmanager gehandhabt werden?

12

Lassen Sie mich zuerst einen Begriff prägen:

Code-Zielsetzung: Code am Morgen auschecken und dann alle Änderungen, die die anderen Entwickler am Vortag vorgenommen haben, Datei für Datei (insbesondere die von Ihnen ursprünglich entwickelten Codedateien) und das Korrigieren von Formatierung, Logik, Umbenennen von Variablen und Umgestalten im Hintergrund überprüfen lange Methoden usw., und dann die Änderungen an das VCS übergeben.

Diese Praxis hat in der Regel ein paar Vor- und Nachteile, die ich identifiziert habe:

  • Pro : Codequalität / Lesbarkeit / Konsistenz wird oft beibehalten
  • Pro : Einige Fehler wurden behoben, weil der andere Entwickler mit dem Originalcode nicht vertraut ist.
  • Con : Ist oft eine Zeitverschwendung des zielstrebigen Entwicklers.
  • Con : Führt gelegentlich Fehler ein, die bei Entwicklern, die dachten, sie hätten am Vortag fehlerfreien Code geschrieben, für Furore sorgen.
  • Con : Andere Entwickler werden durch übermäßiges Nitpicking verärgert und beginnen, Beiträge zum Code des Ziel-Tenders abzulehnen.

Haftungsausschluss: Um fair zu sein, ich bin eigentlich kein Entwicklungsmanager, sondern der Entwickler, der tatsächlich die "Zielverfolgung" durchführt.

Zu meiner Verteidigung denke ich , dass ich dies aus gutem Grund tue (um unsere extrem große Codebasis als gut geölte Maschine zu erhalten), aber ich bin sehr besorgt, dass dies auch eine negative Atmosphäre schafft. Ich bin auch auf jeden Fall besorgt, dass mein Manager das Problem angehen muss.

Wenn Sie der Manager wären, wie würden Sie dieses Problem angehen?

UPDATE: Ich meine nicht, dass dies zu lokalisiert ist, aber einige haben gefragt, also wird vielleicht ein Hintergrund beleuchtet. Vor drei Jahren wurde mir ein Riesenprojekt (200K LoC) zugewiesen, und erst vor kurzem (vor einem Jahr) wurden dem Projekt zusätzliche Entwickler hinzugefügt, von denen einige mit der Architektur nicht vertraut sind, andere die Sprache noch lernen (C #). Im Allgemeinen muss ich für die allgemeine Stabilität des Produkts aufkommen, und ich bin besonders nervös, wenn überraschenderweise Änderungen an den zentralen Architekturteilen der Codebasis vorgenommen werden. Diese Angewohnheit kam zustande, weil ich anfangs optimistisch gegenüber den Beiträgen anderer Entwickler war, aber sie machten zu viele Fehler, die schwerwiegende Probleme verursachten, die erst Wochen später entdeckt wurden, als der Finger auf mich gerichtet wurde, um instabilen Code zu schreiben. Oft diese "

Kevin McCormick
quelle
3
Anscheinend pumpen Ihre Entwickler Ihre Reifen nicht genug. Ersetzen Sie Ihren Torhüter durch FxCop oder ähnliches und setzen Sie diese Standards automatisch durch, damit sie nicht einchecken können.
Jon Raynor
2
Con: Es ist nicht dein Job. Diese Leute sollten ihre eigenen Ziele verfolgen.
Robert Harvey
10
Als Entwickler würde ich es für einen anderen Entwickler ärgerlich finden, dies mit all den Änderungen zu tun, die ich vornehme, und wenn als Ergebnis Bugs wieder eingeführt werden, dann ist es völlig inakzeptabel
Ryathal
4
@ Ryathal: Der Shop sollte einen Codestandard durchsetzen. Code gehört im Allgemeinen dem gesamten Team. Wenn Sie also nicht möchten, dass die Leute ihn ändern, sollten Sie ihn an erster Stelle richtig machen.
Robert Harvey
1
@RobertHarvey Einen Standard durchzusetzen ist eine Sache, ein Schurkenentwickler, der seine Ansicht von "Recht" stillschweigend durchsetzt, ist eine andere Sache, und dies scheint ein Fall von letzterem zu sein.
Ryathal

Antworten:

52

Es hört sich so an, als ob das, was Sie tun, im Grunde einer Codeüberprüfung gleichkommt, außer dass Sie dem Entwickler nicht Feedback geben, sondern alle Änderungen vornehmen, die Sie in einer Codeüberprüfung vorschlagen würden. Mit ziemlicher Sicherheit ist es besser, eine tatsächliche Codeüberprüfung durchzuführen, bei der Sie (oder eine andere Person) dem ursprünglichen Entwickler Feedback zu Problemen mit der Codequalität und offensichtlichen Fehlern geben und den ursprünglichen Entwickler bitten, diese zu beheben. Das hält die Codequalität aufrecht, hilft dem Entwickler aber auch, sich mit dem ursprünglichen Code und seinen Fallstricken vertraut zu machen und zukünftige Codeänderungen zu verbessern. Außerdem hat es nicht den Nachteil, "haarsträubende Wut" zu verursachen, wenn ein Fehler unbemerkt gemeldet wird oder andere Entwickler glauben, dass hinter ihrem Rücken über ihn gesprochen wird.

Justin Cave
quelle
4
Groß +1. Codeüberprüfungen helfen dabei, das Team aufzubauen, während die von ihm beschriebene "Zielverfolgung" den Anschein erweckt, als würde sie die Menschen in die falsche Richtung lenken.
Doug T.
2
Dies. Echte Code-Reviews wären hier ein viel besserer Weg. Die beiden großen Vorteile sind, wie Sie sagten, dass der Entwickler die Anwendungsarchitektur schneller lernt, weil Sie ihm die Probleme zeigen. Das zweite ist, dass Sie keine Bugs einführen werden, weil Sie den neuen Code, der geschrieben wird, nicht vollständig verstehen. Perfekte Antwort auf diese Frage.
Mike Cellini
2
Geniale Antwort und danke für den Einblick. Ich denke, eine Kopie dieser Frage und eine bescheidene Haltung gegenüber meinem Manager könnten ihn davon überzeugen, dass Codeüberprüfungen für das Team von Vorteil sind und den Bedarf an "Zielverfolgung" verringern.
Kevin McCormick
1
Einverstanden. Mische nicht mit dem Code anderer Leute, ohne zu fragen. Sie können auf diese Weise einige knorrige Bugs bekommen. Ich habe zielgerichtete Fehler behoben, die nicht angenehm sind. Wenn Sie Bedenken hinsichtlich der Code-Robustheit haben, schreiben Sie Komponententests.
Paul Nathan
2
Auch wenn Sie nie zu "echten" Code-Überprüfungen übergehen, ist es eine großartige Möglichkeit, einfach mit der anderen Person zu sprechen und zu fragen, warum sie bestimmte Dinge getan haben und warum sie es nicht getan haben Tore. +1
TehShrike
14

Um ehrlich zu sein, IMHO, das ist eine schreckliche Idee.

Ich würde erwarten, dass die Moral in die Gosse fällt, wenn dies nicht schon geschehen ist.

Um fair zu Ihnen zu sein, erkennen Sie dies an.

Peer-Code-Reviews sind in Ordnung, sie stellen die Entwickler auf eine Ebene, anstatt ein "Sie gegen uns" -Szenario zu sein. (wo sie ist Management / führt).

Es mag einige Entwickler geben, die Sie möglicherweise mehr im Auge behalten müssen als andere, aber es ist lächerlich, den gesamten Code dazu zu zwingen, zuerst durch Sie zu kommen.

Und egal wie gut Sie denken, dass Sie sind, es wird Zeiten geben, in denen Sie sich irren oder "nichts aussuchen", und dies wird die Dinge nur noch schlimmer machen.

ozz
quelle
Das und der Manager wird den Code wahrscheinlich eher verschlimmern.
Andy
5

Wenn ich der Manager wäre, um dieses Problem anzugehen:

  • Überprüfen Sie die Codestandards und -praktiken mit dem Team und geben Sie ihnen eine Kopie der Codestandards
  • Peer-Review-Code regelmäßig, um die zu befolgenden Standards und Praktiken zu verstärken
  • Erzwingen Sie Nitpicking / Formatierung mit einem Automatisierungstool, sodass Entwickler gezwungen sind, den Standards zu folgen
  • Werde alle schlechten Teamkollegen los, die sich weigern, Standards zu folgen
  • Hör auf, der Torhüter zu sein

Ihre Absichten sind gut, aber die Implementierung ist schrecklich und wird, wie andere betont haben, zu einer schlechten Moral führen und die Teammitglieder beschneiden.

Wenn das Projekt noch nie einen Standard hatte, versuchen Sie, den neuen Standard schrittweise einzuführen, anstatt nur einen Schalter zu betätigen.

Jon Raynor
quelle
3

Schlechter Juju.

Ich bin kein Entwicklungsmanager, aber wenn ich es wäre, würde ich nicht wollen, dass einer meiner Entwickler Code berührt, der nicht Teil eines Fehlers oder einer ihnen zugewiesenen Funktion ist. Zeitraum. Wenn Sie ein Problem mit dem Code einer anderen Person feststellen, machen Sie den / die zuständigen Entwickler auf jeden Fall darauf aufmerksam. Tauchen Sie jedoch nicht einfach ein und beheben Sie das Problem selbst, insbesondere, wenn Sie nicht mit dem anderen Entwickler abgestimmt haben ( s) zuerst.

Bereinigungsaufgaben sollten nur nach einer formellen Codeüberprüfung durch das Team und nur durch die Entwickler ausgeführt werden, denen diese Aufgaben zugewiesen wurden.

Initiative ist im Allgemeinen gut, aber manchmal kann sie dich in den Arsch beißen. Wenn Sie irgendwelche Fehler in vorstellen , was wurde Code arbeiten, können Sie schnell sein zu wollen Sie einen anderen Karriereweg gewählt würde.

John Bode
quelle