Wie kann man diejenigen "neutralisieren", die schlechten Code in das Team schreiben?

Ich habe diesen Artikel über JoelOnSoftware mit dem Titel "Dinge erledigen, wenn Sie nur ein Grunzen sind" immer geliebt . Ich konnte mich besonders darauf beziehen, als ich Neuling war (und immer noch das Gefühl haben, dass ich IMMER einer sein werde).

Über # 4, die Bozos neutralisieren. Welchen Rat haben Sie, um dies in realen Arbeitssituationen umzusetzen? Es scheint nicht so einfach zu sein (zumindest für unser Team), einfach einen Fehler gegen den schlechten Code einer Person zu protokollieren. Was funktioniert für euch alle da draußen?

team bug

— C Johnson
quelle

Waffen. Viele von ihnen.

— CodesInChaos

Antworten:

Permanente Bewertung.

Nehmen Sie sich am Ende eines jeden Tages 30 Minuten Zeit, um zu überprüfen, was sie geschrieben haben. Wenn sie etwas falsch gemacht haben, lassen Sie sie es neu schreiben.

Wenn Sie dies nicht tun, werden Sie eines Tages feststellen, dass ein Teil Ihrer Anwendung, obwohl er anscheinend in der Lage ist, die Aufgabe zu erledigen, völlig nicht zu warten ist, nicht ordnungsgemäß entwickelt wurde und in Zukunft - oder sogar morgen - viele Probleme verursachen wird.

Selbst wenn es sie weniger produktiv macht, ist es immer noch viel besser, wenn sie guten Code gegen doppelt so große, aber nicht zu wartende Fehler produzieren.

— P Shved
quelle

Gute Antwort. Wenn ich nur daran anhängen kann, wenn diese Person ein Peer ist, dann wird es am besten vom Teamleiter gemacht. Auf diese Weise wäre die Antwort "Nicht gut, es wieder zu tun" viel effektiver, wenn sie von der Hierarchie des Shops befohlen würde.

@ Surfer, es ist genau das Gegenteil. Sie werden zum Teamleiter, indem Sie solche Dinge tun, bessere Lösungen vorschlagen und sich darum kümmern, was das Team tut. Nicht umgekehrt. (Aber natürlich hilft es, Hilfe von höheren Hierarchieebenen zu erhalten).

— P Shved

Es stellt sich also die Frage, wer die Autorität hat, sie dazu zu bringen, es neu zu schreiben. Ich denke, die Antwort ist die moralische Autorität des gesamten Teams, wenn die Probleme an das gesamte Team übertragen werden.

— C Johnson

In Ermangelung eines robusten Mechanismus zur Codeüberprüfung für jedes Teammitglied ist dies angemessen. Es ist auch angebracht sicherzustellen, dass der Bozo kein wirklich tiefes Loch gräbt (auch wenn die Reparaturkosten nicht wert sind), bevor er aufgefordert wird, es zu überarbeiten.

— Mattnz

Wenn die Person es einfach nicht besser weiß, aber lernen möchte, bieten Sie Mentoring und Code-Überprüfung an. Stellen Sie sicher, dass sie gutem Code ausgesetzt sind.

Die wirklich armen Entwickler sind diejenigen, die auf schlechte Weise eingestellt sind und kämpfen, um etwas Neues zu lernen. Ihre einzige Hoffnung ist es, sie leiden zu lassen, indem sie ihr eigenes Chaos oder einige der einfacheren Dinge aufrechterhalten. Im Idealfall steht jemand mit Autorität auf und sagt, sich anzupassen oder zu gehen.

— JeffO
quelle

Die Einstellung zählt wirklich. Normalerweise finde ich Neulinge bescheidener und offen für Code-Reviews und Kritik. Diese Leute sind leicht zu sprechen. Und Sie können leicht mit ihnen über ihre Schwächen sprechen. Es sind die arroganten Veteranen, die wie eine Million Glasstücke zerbrechen, wenn sie wegen ihrer Arbeit kritisiert werden.

— C Johnson