Come gestire i membri del team che scrivono codice errato [duplicato]

Un paio di cose.

1. Non dare per scontato che i tuoi anziani non sappiano cosa stanno facendo. Possono avere ottime ragioni per cui hanno preso le decisioni che hanno fatto; chiedi loro perché (in un modo non-argomentativo ).

2. Il codice che è già stato scritto, supportato da unit test e dichiarato funzionalmente completo dai tuoi superiori può essere tranquillamente ignorato. Questo è quello che dovresti fare con esso: ignoralo, fino a quando non sarà necessario mantenerlo ulteriormente, per qualsiasi motivo.

3. In base alla tua descrizione sommaria, sembra che la tua squadra sia sottoposta a forti pressioni temporali. I compromessi sono fatti in queste condizioni; è proprio così.

Scegli le tue battaglie con saggezza. Combatti solo quelli che hanno bisogno di combattere.

They are not following MINIMUM coding standards.

Se non è il tuo lavoro controllare la codifica degli altri, allora non farlo. È un modo classico per i giovani di fare brutta figura.

Vedi questa domanda per una discussione simile: link

Correlati: un post sul blog in cui ho scritto di non essere d'accordo, e parte di esso è conoscere il tuo posto e quando è opportuno non essere d'accordo e quando non lo è: Come non essere d'accordo senza essere sgradevole

Come altri hanno già detto, dovresti chiedere delle scelte degli sviluppatori senior in modo non conflittuale, ma potrebbe anche valerne la pena esaminare alcune cose.

Prima di tutto: c'è uno standard di codifica che il progetto segue? Se non è definito uno standard di codifica, nessuno sta infrangendo lo standard di codifica. Lo "standard" potrebbe semplicemente consistere nel rendere il nuovo codice simile al vecchio codice. Questa è una posizione sfortunata in cui stare, ma uno standard di codifica ad hoc è ancora uno standard di codifica.

Se esiste uno standard di codifica: chi garantisce la sua implementazione? Tutti gli sviluppatori sono responsabili, vengono gestiti durante i periodi di revisione, ecc.

Ti darò il mio esempio: sono arrivato a un progetto che è appena agli inizi. Abbiamo membri anziani, ma soprattutto juniores (me compreso). Come si è scoperto, ero quello che era più preoccupato per uno standard di codifica. La nostra politica aziendale e di controllo qualità impone che abbiamo uno standard e, dato che sono stato io a portarlo a termine, è stato il mio lavoro trovarne uno.

È risultato essere estremamente facile. C'è uno standard per Java impostato da Oracle, il che rende questa la scelta più ovvia. Successivamente, ho trovato uno strumento per Java chiamato Checkstyle, che applica gli standard di codifica per te. Ogni volta che apporti una modifica e salvi un file, Checkstyle esegue il file per eventuali violazioni dello standard di codifica che hai, e illumina tutte le violazioni come un avvertimento. Inoltre, esegue alcuni compiti di analisi statica: complessità N-Path, complessità ciclomatica, ecc. Dopo di ciò, ho esaminato il formattatore di Eclipse e ho scoperto che potevo renderlo conforme anche al nostro standard di codifica. Quindi ora, dopo una minima quantità di configurazione, abbiamo uno strumento che:

• Luci alte che codificano violazioni standard
• Un formatter che può essere invocato con ctrl + shift + F
• Zero manutenzione
• Non viene speso tempo nelle revisioni del codice per problemi standard di codifica di base (scheda qui, spazio lì, commento necessario qui, ecc.)

Quindi, in definitiva, per trattare con il mantenimento di uno standard di codifica, vorrei:

1. Chiedi qual è lo standard corrente, è definito da qualche parte e tutti gli sviluppatori ne sono a conoscenza?
2. Prepara un piano - fai alcuni compiti a casa e cerca strumenti nella lingua del tuo progetto che ti possano aiutare a fare ciò che ho fatto. Seriamente: avere uno standard di codifica sul posto che tutti seguono è grandioso. Ho finito per renderlo così facile da fare che nessuno aveva un motivo non per seguirlo.
3. Una volta che hai un piano, prova a parlarne al tuo supervisore. Dì loro il tuo piano e, cosa ancora più importante, dì loro come questo potrebbe farli risparmiare tempo in futuro avendo meno difetti nel codice.

Esercita la pratica dell'apertura in un ambiente professionale - se ritieni che il loro codice possa essere migliorato e hai una buona ragione per affermare che dovrebbero farlo in modo diverso, non ci dovrebbe essere nulla nel tuo modo di suggerirlo (finchè come non sei condiscendente o così).  Se lavori in un luogo in cui l'apertura è disapprovata, non so se sia particolarmente salutare. Potrebbero avere un'idea eccellente del motivo per cui stanno facendo qualcosa che non hai notato o il contrario - qualcuno è destinato a imparare qualcosa semplicemente facendo domande:)