Come "neutralizzare" coloro che scrivono codice errato nella squadra?

Ho sempre adorato questo articolo su JoelOnSoftware chiamato "Far fare le cose quando sei solo un grugnito". Potrei relazionarmi soprattutto quando ero novizio (e sento ancora che lo farò SEMPRE).

Circa # 4, neutralizzando i bozo. Che consiglio hai per implementarlo effettivamente in situazioni reali di lavoro? Non sembra essere così facile (almeno nella nostra squadra) come semplicemente registrare un bug contro il codice errato di qualcuno. Cosa funziona per tutti gli altri là fuori?

team bug

— C Johnson
fonte

Guns. Molti di loro.

— CodesInCos

Risposte:

Valutazione permanente.

Alla fine di ogni giornata spendi 30 minuti per rivedere ciò che hanno scritto. Se hanno fatto qualcosa di sbagliato, falli riscrivere.

A meno che tu non lo faccia, un giorno ti renderai conto che una parte della tua applicazione, pur essendo apparentemente in grado di fare il lavoro, è totalmente non realizzabile, progettata in modo improprio e causerà molti problemi in futuro, o anche in futuro.

Anche se li renderà meno produttivi, sarebbe comunque molto meglio se producessero un buon codice contro dimensioni due volte più ma un gonfio di bug non mantenibili.

— P rasato
fonte

Bella risposta. Se posso solo accontentarlo, se questa persona è un pari, allora è meglio farlo dal capo squadra. In questo modo la sua risposta non buona sarebbe molto più efficace se comandata dalla gerarchia del negozio.

@Surfer, è esattamente il contrario. È diventato un leader della squadra facendo cose come questa, proponendo soluzioni migliori, per la cura quello che la squadra fa. Non viceversa. (Ma, naturalmente, ottenere aiuto da livelli gerarchici più alti aiuta).

— P:

Quindi la domanda diventa: chi ha l'autorità per farli riscrivere? Immagino che la risposta sia l'autorità morale dell'intera squadra, se i problemi vengono trasmessi all'intera squadra.

— C Johnson,

In assenza di un solido meccanismo di revisione del codice per ogni membro del team, questo è appropriato. È inoltre opportuno assicurarsi che il bozo non scavi un buco molto profondo (anche se non vale il costo del fissaggio) prima di sentirsi dire di rielaborarlo.

— Mattnz,

Se la persona semplicemente non conosce meglio, ma vuole imparare, fornisci un tutoraggio e una revisione del codice. Assicurati che siano esposti a un buon codice.

Gli sviluppatori davvero poveri sono quelli che sono messi in cattive condizioni e lottano per imparare qualcosa di nuovo. La tua unica speranza è di lasciarli soffrire mantenendo il loro pasticcio o alcune delle cose più semplici. Idealmente, qualcuno in autorità si alza in piedi e dice conformarsi o andarsene.

— Jeffo
fonte

L'atteggiamento conta davvero. Di solito trovo il novizio più umile e aperto alle recensioni e alle critiche del codice. Queste persone sono facili da parlare. E puoi facilmente parlare con loro delle loro debolezze. Sono gli arroganti veterani, che si frantumeranno come un milione di pezzi di vetro quando saranno criticati per il loro lavoro.

— C Johnson,