Wie entwaffnet man einen Cowboy-Codierer? [geschlossen]

37

Ich habe eine Frage gefunden (Code Cowboy im Team), aber sie hatte mehr mit "Ninja Coder" zu tun als mit dem Problem, das ich habe.

Ich habe ein Teammitglied, das ein lebendiges Beispiel für " Cowboy Coder " ist. Ich verstehe, dass man die Leute nicht ändern kann, aber kann man ihn dazu bringen, sich nicht mehr wie ein "Cowboy Coder" zu verhalten?

Er weigert sich, dem Team zuzuhören, und hat kürzlich die Überprüfung von Codes, Unit-Tests, die Weitergabe von Implementierungsdetails usw. eingestellt.

Ja, er "codiert" schnell, aber sein Code ist nur ein Fehlergenerator. Andere Teammitglieder und ich befinden uns in einer "Fehlerbehebungsphase" und 80% der Fehler stammen aus seinem Code. Ich möchte seine Fehler nicht beheben. Und das Management ist blind oder will das nicht sehen, oder vielleicht mögen sie seine "Geschwindigkeit".

Gibt es eine Möglichkeit, wie ich (als sein jüngerer Kollege, nicht sein Chef) etwas dagegen tun kann?

Wie kann ich diesen Cowboy-Codierer entschärfen?

Ich fühle mich als der Letzte, der sich wirklich um das Projekt kümmert.

Adronius
quelle
17
Dieser Typ muss seine eigenen Fehler beheben. Warum muss nicht jeder Entwickler Codeüberprüfungen durchführen?
Programmierer
8
Unter wem hat er die Codeüberprüfung eingestellt?
Otávio Décio
14
Also ... du hast nicht einen, der dieses Ding managt. Das ist dein Problem, nicht der Cowboy-Coder.
Otávio Décio
3
Wenn dies der Fall ist, ist Scrum ein Prozess, der für nichts gut ist. Wenn alle verantwortlich sind, ist niemand verantwortlich, und das Produkt leidet unter dem Nebeneffekt.
Otávio Décio
7
Aber wie entwaffnen wir "close thread" Cowboys ...
Rig

Antworten:

21

Ich sehe ein paar Möglichkeiten:

  • Sprechen Sie den Programmierer mit Ihren Bedenken an. Es muss als konstruktive Kritik mit bestimmten Punkten erfolgen. Bevor Sie größere Schritte unternehmen, ist es angebracht, Bedenken direkt und privat zu äußern, um der Person die Möglichkeit zu geben, sich zu ändern.
  • Sammeln Sie Informationen und Statistiken und bringen Sie sie zum Management. Das Management scheint sich nicht darum zu kümmern, aber es ist oft wichtig, sich trotzdem anzustrengen, falls es funktioniert. Mögliche negative Folgen sind die Entfremdung anderer, die Beschwerden an das Management nicht schätzen.
  • Finden Sie einen Kollegen des Cowboy-Programmierers und diskutieren Sie unter vier Augen. Möglicherweise hat er / sie eine bessere Chance, die Person zum Zuhören zu bewegen.
  • Bitten Sie darum, in einem anderen Team zu arbeiten. Das Problem wird nicht gelöst, aber Sie werden Ihre geistige Gesundheit bewahren. Arbeiten Sie zumindest immer nach besten Kräften und lassen Sie sich nicht davon runterziehen.
  • Verlasse die Organisation, wenn niemand zuhört. Es klingt nach einer schlechten Umgebung.
Matt S
quelle
6

Er weigert sich, dem Team zuzuhören, und hat kürzlich die Überprüfung von Codes, Unit-Tests und die Weitergabe von Implementierungsdetails eingestellt ...

Code-Überprüfungen erfordern nicht unbedingt, dass der Codierer die Arbeit zur Überprüfung einreicht.

Eine einfache Möglichkeit, den Überblick zu behalten, besteht darin, die VCS-Historie zu verfolgen und nach seinen Eincheckvorgängen zu suchen. Wenn Sie sich Sorgen um seinen Code machen, können Sie ihn auf einfache Weise finden. Holen Sie sich einen Diff-Verlauf, sehen Sie sich an, was er eingegeben hat, und prüfen Sie, ob rote Fahnen auf Sie losgehen. Wenn Sie ein Problem feststellen, können Sie das Commit zurücksetzen und ihm eine E-Mail senden. Sie dürfen Ihre Teamkollegen auch als Junior-Programmierer anrufen, wenn Sie einen offensichtlichen Fehler feststellen.

Ja, er "codiert" schnell, aber sein Code ist nur ein Fehlergenerator. Andere Teammitglieder und ich befinden uns in einer "Fehlerbehebungsphase" und 80% der Fehler stammen aus seinem Code. Ich möchte seine Fehler nicht beheben. Und das Management ist blind oder will das nicht sehen, oder vielleicht mögen sie seine "Geschwindigkeit".

Code kommt aus Anforderungen. Anforderungen führen zu ausführbaren Tests, die bestätigen, dass die Anforderungen erfüllt wurden. Diese Tests können weiter unterteilt und geschrieben werden, bevor Änderungen vorgenommen werden, um zu überprüfen, ob die Änderungen den Anforderungen entsprechen (Rot-Grün-Refaktor; das Wesen von TDD).

Fügen Sie dem Build-Server Ihres Teams eine Metrik für die Codeabdeckung hinzu (hoffentlich haben Sie eine, wenn nicht, ist dies Ihr erstes Problem). Durch einfaches Überprüfen, ob die Komponententests bestanden wurden, werden die Probleme mit seinem neuen Code (ohne TDD), der in Bereichen ohne Komponententests erstellt wurde, nicht behoben. Nachdem Sie alle Komponententests ausgeführt haben, sollte der Build-Server im Idealfall jede Codezeile ausgeführt haben, aber es gibt tatsächlich einige Dinge, die Sie einfach nicht testen können. Realistisch gesehen sollten Sie immer noch in der Lage sein, eine Abdeckung von 95% oder besser zu erwarten (oder bestimmte Bibliotheken oder Dateitypen von der Abdeckung auszuschließen). Früher oder später checkt Ihr Cowboy etwas ein, das den Build unterbricht, weil er den Abdeckungsgrad unter den Schwellenwert gesenkt hat, und Sie rufen ihn an.

Und was "Geschwindigkeit" betrifft, ist Geschwindigkeit, wie schnell Sie Dinge "erledigen" und erst dann "erledigen", wenn sie korrekt erledigt sind. Sie können es auf diese Weise Ihren Managern mitteilen. Betrachten Sie einen Automechaniker, der vergisst, wenn der Manager seinen BMW zum Ölwechsel mitnimmt, die Ölwanne wieder einzustecken, und infolgedessen läuft das gesamte neue Öl aus, bevor er überhaupt aus der Garage fährt. Sicher, der Ölwechsel dauerte nur fünf Minuten, aber der Manager wird sich nicht darum kümmern, wenn der Motor seines Autos auf dem Heimweg festsitzt. Er wird sich darum kümmern, dass der Mechaniker einen Schritt verpasst hat, was ihn viel zusätzliche Zeit und Geld kosten wird, um ihn zu reparieren. Im Moment bezahlt er einen Cowboy, um die Arbeit wirklich schnell zu erledigen, und dann Wir zahlen dem Rest des Teams eine viel größere Summe, um die Arbeit korrekt zu erledigen. Was ist eigentlich der Vorteil, den Cowboy weiterhin sein Ding machen zu lassen?

Gibt es eine Möglichkeit, wie ich (als sein jüngerer Kollege, nicht sein Chef) etwas dagegen tun kann?

Ruf ihn raus. Wenn Sie etwas finden, das er vermasselt hat, zeigen Sie ihm, wie sein Code versagt, wie er das Problem an erster Stelle hätte verhindern können (einschließlich korrektem Design, TDD, Codeüberprüfungen) und was Sie als Ergebnis tun mussten oder müssen um seinen kaputten Code zu reparieren.

Ich fühle mich als der Letzte, der sich wirklich um das Projekt kümmert.

Klatschen, Lichter blinken, Sirenen heulen - wenn Sie wirklich das Gefühl haben, die einzige Person zu sein, die sich um die Qualität des vom Team erstellten Codes kümmert, gibt es ein SCHWERES Problem. Wenn Sie das Gefühl haben, dass Sie versuchen, das gesamte Team in die Ära des guten Codierens zu schleppen, und es einfach zu schwer ist, um es zu schleppen, lassen Sie es fallen. Wenn es ein anderes Team in der Firma gibt, das es richtig macht, bitten Sie um einen Transfer, sonst kommen Sie zum Teufel raus.

KeithS
quelle
5

Wenden Sie sich mit Ihren Statistiken darüber, wie viele Bugs / Probleme von diesem einen Entwickler stammen, an das Management. Erklären Sie ihnen, dass die Behebung ihrer Fehler die Produktivität Ihres Teams beeinträchtigt. Wenn tatsächlich 80% der Probleme von einer Person stammen, muss dies unbedingt angegangen werden. Solange Sie es dem Management in einer Weise erklären, mit der es einverstanden ist (dh "Zeitverschwendung ist Geldverschwendung"), werden sie eingreifen.

Außerdem sollte dieser Entwickler seine eigenen Fehler / Probleme beheben, sodass es hilfreich sein kann, diese Probleme ihnen zuzuweisen. Ihr Team sollte diese eine Person nicht abdecken.

Bernard
quelle
4

Gibt es eine Möglichkeit, wie ich (als sein jüngerer Kollege, nicht sein Chef) etwas dagegen tun kann?

Gruppenzwang und Vorbildfunktion sind die einzigen guten Wege. Die besten Wege gehen von ihrem Chef / Leiter aus. Wenn Sie nicht ihr Chef / Leiter sind, dann sprechen Sie mit denen, die es sind. Aber am Ende ist es ihre Aufgabe, sich darum zu kümmern, nicht deine. Stellen Sie sicher, dass Sie einen guten Job machen und die Dinge dazu neigen, sich von selbst zu verbessern.

Telastyn
quelle
1
Der Cowboy-Codierer ist möglicherweise immun gegen Druck. Wenn das Management seine tatsächlichen Auswirkungen nicht versteht, werden sie möglicherweise von seinen wahrgenommenen Auswirkungen geblendet.
mhoran_psprep
Er kann seine Fehler sehr gut vor dem Management vertreten, so dass große Fehler oder Probleme für das Management klein erscheinen, aber am Ende bleibt der Code ruiniert. Und das ist dem Management egal.
Adronius
2
@mhoran_psprep - Oh sicher. Ich erwarte nicht, dass er erfolgreich ist , aber ich denke auch, dass der Versuch, die Dinge anders zu regeln, riskanter ist, wenn es um negative Konsequenzen geht. Es ist eine schnelle und einfache Möglichkeit, sich zu ärgern, besonders wenn die Wahrnehmung des Cowboys in der OP ungenau ist.
Telastyn
0

Er weigert sich, dem Team zuzuhören, und hat kürzlich die Überprüfung von Codes, Unit-Tests und die Weitergabe von Implementierungsdetails eingestellt ...

Haben Sie keinen dokumentierten Pfad für Code durch Überprüfung, Testen und Implementierung? Wenn nicht, haben Sie ein größeres Problem. Wenn Sie dies tun, ist dies etwas, das eskaliert werden muss.

Versuchung
quelle
Sicher, wir haben Tonnen von Prozessen und Dokumenten. Aber es geht um Menschen, wie sie sie benutzen .
Adronius
Es sollte jedoch nichts in die Produktion gelangen, ohne eine entsprechende Freigabe zu erhalten. Wollen Sie mir sagen, dass er die normale Änderungskontrolle umgeht?
Versuch
Nicht genau, aber irgendwie. Er nimmt Änderungen am Code vor und führt dann die "formalen" Schritte durch, um die Codeüberprüfung durchzuführen = verwendet nur ein Tool von ihm selbst, sodass der Code das Flag "überprüft" hat oder seinen Partner (der sich nicht um Code kümmert) darum bittet "überprüfen" Sie seinen Code. Dann "erklärt" er den Code in einer Minute und es ist erledigt. Huray, und er geht, um die Änderungen einzureichen.
Adronius