Cosa dici in una revisione del codice quando l'altra persona ha creato una soluzione troppo complicata? [chiuso]

L'altro giorno ho esaminato il codice scritto da qualcuno nel mio team. La soluzione non era completamente funzionale e il design era molto complicato, il che significava immagazzinare informazioni non necessarie, creare funzionalità non necessarie e fondamentalmente il codice presentava molte complessità non necessarie come la doratura e ha cercato di risolvere problemi che non esistono.

In questa situazione chiedo "perché è stato fatto in questo modo?"

La risposta è che l'altra persona ha voglia di farlo in quel modo.

Quindi chiedo se una qualsiasi di queste funzionalità faceva parte delle specifiche del progetto, o se hanno qualche utilità per l'utente finale o se uno qualsiasi dei dati extra fosse presentato all'utente finale.

La risposta è no.

Quindi suggerisco di eliminare tutta la complessità non necessaria. La risposta che di solito ricevo è "beh, è ​​già fatto".

La mia opinione è che non è fatto, è difettoso, non fa ciò che gli utenti vogliono e i costi di manutenzione saranno più alti che se fossero fatti nel modo più semplice che ho suggerito.

Uno scenario equivalente è: il
collega spende manualmente 8 ore di codice di refactoring che avrebbe potuto essere eseguito automaticamente in Resharper in 10 secondi. Naturalmente non mi fido del refactoring a mano poiché è di dubbia qualità e non completamente testato.
Ancora una volta la risposta che ottengo è "beh, è ​​già stata fatta".

Qual è la risposta appropriata a questo atteggiamento?

Mentalità / atteggiamento

• Dare l'esempio
• Admonish in private (one-to-one, al di fuori della revisione del codice)
• Incoraggia una mentalità Keep-it-simple tra i membri del team

Gestione della squadra

• Dedica più tempo alla specifica di un elemento di lavoro (come architettura, struttura dell'algoritmo, wireframe dell'interfaccia utente, ecc.)
• Incoraggia i membri del team a chiedere chiarimenti sulla portata di un oggetto di lavoro
• Incoraggia i membri del team a discutere su come implementare un oggetto di lavoro
• Fai delle stime ragionevoli per ciascun oggetto di lavoro prima di iniziare e fai il possibile per soddisfarli
• Monitorare il "miglioramento" dei membri del team.
  • Dopo essere stato ammonito o aver mostrato il modo giusto di fare le cose, vedi se il membro del team migliora.

Livello di abilità

• Dedica del tempo alle sessioni di programmazione in coppia o alle sessioni di formazione one-to-one per sfruttare al meglio gli strumenti per sviluppatori (refactoring, revisione del codice)

Gestione del progetto (rischio)

• Esegui la revisione del codice più spesso, in modo asincrono (Nota)
  • Nota su "in modo asincrono"
    • Il revisore del codice dovrebbe ricevere notifiche / inviti a rivedere le modifiche non appena eseguito il commit
    • Il revisore del codice dovrebbe avere la possibilità di rivedere il codice prima di qualsiasi incontro con lo sviluppatore.
    • Se è necessario un chiarimento da parte dello sviluppatore, fallo in modo informale su IM / e-mail senza esprimere un'opinione negativa

Cosa dici in una revisione del codice quando l'altra persona ha creato una soluzione troppo complicata?

Dici: "hai costruito una soluzione eccessivamente complicata".

Quindi suggerisco di eliminare tutta la complessità non necessaria. La risposta che di solito ricevo è "beh, è ​​già fatto".

Se è troppo tardi per cambiare qualcosa, perché stai facendo una revisione del codice?

"È già fatto" non è una risposta soddisfacente. Fatto significa testato e funzionante. Ogni codice aggiuntivo che non sta facendo nulla di utile dovrebbe essere mantenuto nel modo corretto (eliminato).

Assegnagli di nuovo questo compito chiedendo di refactoring e ottimizzare la sua soluzione. Se non lo fa, assegnagli un programmatore di coppia e spera che imparerà qualcosa dal collega.

Quindi suggerisco di eliminare tutta la complessità non necessaria. La risposta che di solito ricevo è "beh, è ​​già fatto".

Questa non è una risposta accettabile:

• Se è davvero troppo tardi per cambiare, la revisione del codice sarà in gran parte una perdita di tempo e la direzione deve saperlo.

• Se questo è davvero un modo di dire "Non voglio cambiare", allora devi prendere la posizione che la complessità extra è MALE per la base di codice PERCHÉ i problemi / i costi che dovranno sostenere in seguito. E riducendo il potenziale per problemi futuri la vera ragione per cui stai facendo la revisione del codice in primo luogo.

E ...

... la soluzione non era completamente funzionale ...

Questo è probabilmente il risultato diretto della complessità inutile. Il programmatore lo ha reso così complesso che non lo capisce più completamente e / o ha perso tempo a implementare la sua complessità piuttosto che i punti funzione. Vale la pena sottolineare al programmatore che tagliare la complessità potrebbe effettivamente portarlo a un programma di lavoro più veloce.

Ora, sembra che tu non abbia il potere (o forse la fiducia) di "spingere forte" su questo. Ma anche così, vale la pena fare un po 'di rumore su questo (senza personalizzarlo) nella speranza che il programmatore offensivo farà un lavoro migliore ... la prossima volta.

Qual è la risposta appropriata a questo atteggiamento?

In definitiva, portalo all'attenzione del management ... a meno che tu non abbia il potere di risolverlo da solo. (Certo, questo non ti renderà popolare.)

Avevi ragione, avevano torto:

• principio YAGNI infranto
• principio KISS infranto
• il codice è completamente testato? Se no, allora non è fatto

Qual è la risposta appropriata a questo atteggiamento?

Esegui la corretta revisione del codice. Se si rifiutano di implementare le modifiche suggerite senza un motivo, smettere di perdere tempo con le recensioni di un codice. Puoi anche inoltrare il problema al loro capo .

Un'azione intrapresa dal nostro team, che ha notevolmente migliorato la situazione in questi casi, è stata il passaggio a cambiamenti molto più piccoli .

Invece di lavorare su un'attività per un giorno o più e quindi avere una (grande) revisione del codice, proviamo a fare il check-in molto più spesso (fino a 10 volte al giorno). Naturalmente ciò presenta anche alcuni inconvenienti, ad esempio il revisore deve essere molto reattivo, il che riduce il proprio output (a causa di frequenti interruzioni).

Il vantaggio è che i problemi vengono rilevati e possono essere risolti in anticipo, prima che venga eseguita una grande quantità di lavoro nel modo sbagliato.

Dovresti concentrarti sulla causa principale del problema:

1. La formazione dei programmatori si concentra sulla crescente complessità data ai programmatori. La capacità di farlo è stata testata dalla scuola. Quindi molti programmatori penseranno che se implementano una soluzione semplice, non hanno fatto il loro lavoro correttamente.
2. Se il programmatore segue lo stesso schema che ha fatto centinaia di volte mentre era all'università, è proprio come pensano i programmatori: più complessità è più stimolante e quindi migliore.
3. Quindi, per risolvere questo problema, dovrai mantenere una separazione rigorosa di ciò che i requisiti della tua azienda sono relativi alla complessità rispetto a quanto è normalmente richiesto nella formazione del programmatore. Un buon piano è una regola del tipo "il livello di massima complessità dovrebbe essere riservato solo alle attività progettate per migliorare le tue capacità e non dovrebbe essere usato nel codice di produzione".
4. Sarà una sorpresa per molti programmatori il fatto che non siano autorizzati a realizzare i loro progetti più folli nell'importante ambiente del codice di produzione. Riservare il tempo ai programmatori per fare progetti sperimentali, e quindi mantenere tutta la complessità in quel lato della recinzione.

(nella revisione del codice è già troppo tardi per cambiarlo)

Non so nulla che funzioni dopo che il codice è stato scritto.

Prima che il codice sia scritto, le persone possono discutere di modi alternativi per farlo. La chiave sta contribuendo le idee tra loro, quindi si spera che ne venga scelta una ragionevole.

C'è un altro approccio che funziona con gli appaltatori: i contratti a prezzo fisso. Più semplice è la soluzione, più $$ il programmatore riesce a mantenere.

Non puoi aggiustare il mondo.

Non puoi nemmeno aggiustare tutto il codice sul tuo progetto. Probabilmente non puoi correggere le pratiche di sviluppo del tuo progetto, almeno non questo mese.

Purtroppo, ciò che stai vivendo nella revisione del codice è fin troppo comune. Ho lavorato in un paio di organizzazioni in cui mi sono trovato spesso a rivedere 100 righe di codice che avrebbero potuto essere scritte in dieci, e ho avuto la stessa risposta che hai fatto: "È già scritto e testato" o "Stiamo cercando bug, non una riprogettazione ".

È un dato di fatto che alcuni dei tuoi colleghi non possono programmare nel miglior modo possibile. Alcuni di loro potrebbero essere piuttosto cattivi. Non ti preoccupare. Un paio di lezioni con cattive implementazioni non faranno cadere il progetto. Concentrati invece sulle parti del loro lavoro che influenzeranno gli altri. I test unitari sono adeguati (se li hai)? L'interfaccia è utilizzabile? È documentato?

Se l'interfaccia per il codice errato è ok, non preoccuparti finché non devi mantenerlo, quindi riscrivilo. Se qualcuno si lamenta, chiamalo refactoring. Se si lamentano ancora, cerca una posizione in un'organizzazione più sofisticata.

Nel progetto dovrebbe esserci una politica standard che controlli le procedure di verifica della qualità e gli strumenti utilizzabili.

Le persone dovrebbero sapere cosa dovrebbero fare e quali strumenti sono accettati per l'uso in questo progetto.

Se non l'hai ancora fatto, organizza i tuoi pensieri e fallo.

La revisione del codice dovrebbe avere un elenco di controllo di articoli standard. Se ottieni "è già fatto" e non lo è, allora personalmente, non vorrei essere responsabile del lavoro di questo sviluppatore come project manager o sviluppatore senior. Questo atteggiamento non deve essere tollerato. Riesco a capire litigare su come fare qualcosa o anche ogni cosa, ma una volta accettata una soluzione, la menzogna non dovrebbe essere tollerata e ciò dovrebbe essere chiaramente affermato.

Il tuo negozio deve applicare alcune metodologie di progettazione.

• I requisiti devono essere definiti chiaramente.
• È necessario sviluppare casi d'uso a supporto dei requisiti.
• È necessario specificare le funzioni necessarie per implementare i casi d'uso.
• È necessario specificare eventuali requisiti non funzionali (tempi di risposta, disponibilità ecc.)
• È necessario un RTM (Requiements Tracabilty Matrix) per mappare ciascuna funzione del sistema su un caso d'uso e un requisito reale.
• Eliminare qualsiasi funzione che non supporta un requisito effettivo.
• Infine, nella revisione del codice contrassegnare qualsiasi codice che non implementa o supporta direttamente le funzioni definite.

Probabilmente non è eccessivamente complicato perché in seguito la maggior parte delle persone si sente male. Presumo che quando ciò accade già sia stato scritto molto codice senza parlarne. (Perché è così? Perché quella persona ha abbastanza autorità in modo che il suo codice non debba essere rivisto nella realtà?)

Altrimenti immagino di rendere la revisione del codice meno formale ma più frequente. E prima di scrivere moduli di grandi dimensioni forse dovresti discutere rapidamente quale approccio adottare.

Dire "questo è troppo complicato" non ti porta da nessuna parte.

È un peccato, ma le recensioni dei codici sono, molte volte, più per il futuro che per il presente. Soprattutto in un ambiente aziendale / aziendale, il codice spedito è sempre più prezioso del codice non spedito.

Questo, ovviamente, dipende dal completamento della revisione del codice. Se fa parte del processo di sviluppo, è possibile ottenere subito alcuni vantaggi. Ma se il CR viene trattato come più di un post-mortem, allora è meglio sottolineare cosa potrebbe essere fatto meglio in futuro. Nel tuo caso (come altri hanno già detto), sottolinea YAGNI e KISS in generale, e forse alcune delle aree specifiche in cui questi principi potrebbero essere applicati.

Che cosa significa eccessivamente complicato? Fai una dichiarazione ambigua e otterrai una risposta ambigua / insoddisfacente in risposta. Ciò che è eccessivamente complicato per una persona è perfetto per un'altra.

Lo scopo di una recensione è di evidenziare problemi ed errori specifici, per non dire che non ti piace, ed è ciò che implica l'affermazione "troppo complessa".

Se vedi un problema (eccessivamente complicato), allora dì qualcosa di più concreto come:

• La modifica della parte da X a Y non semplificherebbe il codice o faciliterebbe la comprensione?
• Non capisco cosa stai facendo qui nella parte X, penso che quello che stavi cercando di fare sia questo. Presentare un modo più pulito di farlo.
• Come hai provato questo? Hai provato questo? Se è eccessivamente complicato, questo di solito porta a sguardi vuoti. La richiesta di test spesso induce la persona a semplificare autonomamente il proprio codice quando non è in grado di capire come testare il codice originale.
• Sembra che ci sia un errore qui, la modifica del codice in questo risolverà il problema.

Chiunque può segnalare problemi, in particolare quelli ambigui. C'è un sottoinsieme molto più piccolo che può presentare soluzioni. I commenti delle recensioni dovrebbero essere quanto più specifici possibile. Dire che qualcosa è eccessivamente complesso non significa molto, può anche indurre gli altri a pensare che NON siete in grado di comprendere il codice. Tieni presente che la maggior parte degli sviluppatori non ha idea della differenza tra un design buono o cattivo.

A volte vale la pena, in gruppo, concentrarsi su alcuni dei principi "Agili": possono aiutare un gruppo o un individuo che sembra essere un po 'fuori rotta.

Concentrarsi non deve significare una grande rielaborazione della tua squadra, ma dovresti sederti tutti a discutere delle pratiche più importanti per te come squadra. Suggerirei di discutere almeno questi (e probabilmente molti altri):

• Fai la cosa più semplice che potrebbe funzionare?
• Non ne avrai bisogno (stai risolvendo problemi che non erano nelle specifiche)
• Scrivi il test prima della codifica (ti aiuta a focalizzare il tuo codice)
• Non ripeterti

Anche revisioni occasionali (settimanali?) Su ciò che funziona, cosa non funziona e ciò che è ancora necessario possono essere davvero utili ... Se non altro, perché non impegnarsi per un'ora a settimana per discutere dei valori e delle pratiche del team?

Escalation, se hai un manager tecnicamente preparato. Sembra un'abitudine che deve essere spezzata.

Se il codice non è stato creato su specifica, per definizione dovrebbe non riuscire a rivedere il codice. Non capisco il concetto di "bene abbiamo fatto qualcosa che nessuno ha chiesto, e non funziona, quindi lo lasceremo lì invece di fare qualcosa che qualcuno ha chiesto che funzioni".

Questa è una cattiva abitudine per qualsiasi sviluppatore. Se lui / lei stava lavorando a una specifica di design, non abbinarla senza una buona ragione è un no no.

Una sola parola: agile

Certamente non risolve tutto. Ma regnando nelle tue iterazioni (1-2 settimane, per esempio), limitando i lavori in corso e sfruttando la pianificazione / revisione degli sprint, dovresti evitare questi errori simili a cascate. Hai bisogno di una migliore visibilità su ciò che viene effettivamente fatto, mentre è in corso.

Per il normale sviluppo basato su progetti, consiglierei di adottare un approccio Scrum . Per ambienti di sviluppo / integrazione continui, e specialmente se hai molti sviluppatori che lavorano su progetti identici o correlati, considera di incorporare elementi di Kanban . Un altro approccio efficace è sfruttare la programmazione di coppie , una pratica definita di programmazione Extreme .

La tua situazione è quasi unica. E anche con piccoli team, il processo può fare molto per evitare la situazione in cui ti trovi adesso. Con un'adeguata visibilità e un arretrato ragionevolmente curato, domande come queste diventano decisioni sprint di pianificazione - salvandoti dalla gestione del debito tecnico .

Quello che ho detto in passato è "questo codice è complesso e non sono sicuro di ciò che sta cercando di fare, è possibile semplificarlo o scriverlo più chiaramente?"

Devi programmare dopo aver eliminato / ripristinato il loro codice: "Spiacenti, il tuo codice è sparito. Ti preghiamo di riscriverlo. Come hai già scritto una volta, avrai bisogno di meno di venti minuti per fornire SOLO il codice richiesto dalla specifica.

"La mia prossima recensione è tra 20 minuti.

"Buona giornata."

NON accettare alcun argomento!

Fatto, IMHO

Chris