Cosa fare quando il codice inviato per la revisione del codice sembra essere troppo complicato?

Il codice è difficile da seguire ma sembra (per lo più) funzionare bene, almeno con test superficiali. Potrebbero esserci piccoli bug qua e là, ma è molto difficile capire leggendo il codice se sono sintomatici di problemi più profondi o semplici correzioni. La verifica manuale della correttezza generale tramite la revisione del codice è tuttavia molto difficile e dispendiosa in termini di tempo, se possibile.

Qual è il miglior modo di agire in questa situazione? Insistere su un rifacimento? Rinnovo parziale? Prima il factoring? Risolvi solo i bug e accetta il debito tecnico ? Effettuare una valutazione del rischio su tali opzioni e poi decidere? Qualcos'altro?

Se non può essere esaminato, non può passare la revisione.

Devi capire che la revisione del codice non è per la ricerca di bug. Ecco a cosa serve il QA. La revisione del codice serve a garantire che sia possibile una futura manutenzione del codice. Se non riesci nemmeno a seguire il codice ora, come puoi in sei mesi quando ti viene assegnato il compito di migliorare le funzionalità e / o correggere i bug? Trovare bug in questo momento è solo un vantaggio collaterale.

Se è troppo complesso, sta violando un sacco di principi SOLIDI . Refactor, refactor, refactor. Suddividilo in funzioni correttamente denominate che fanno molto meno, più semplici. Puoi ripulirlo e i tuoi casi di test si accerteranno che continui a funzionare correttamente. Hai dei casi di test, giusto? In caso contrario, dovresti iniziare ad aggiungerli.

Tutto ciò che menzioni è perfettamente valido per essere sottolineato in una recensione di codice.

Quando ricevo una revisione del codice, rivedo i test. Se i test non forniscono una copertura sufficiente, è qualcosa da sottolineare. I test devono essere utili per garantire che il codice funzioni come previsto e continuerà a funzionare come previsto nelle modifiche. In effetti, questa è una delle prime cose che cerco in una recensione di codice. Se non hai dimostrato che il tuo codice soddisfa i requisiti, non voglio investire il mio tempo a guardarlo.

Una volta che ci sono prove sufficienti per il codice, se il codice è complesso o difficile da seguire, è anche qualcosa che gli umani dovrebbero guardare. Gli strumenti di analisi statica possono indicare alcune misure di complessità e contrassegnare metodi troppo complessi, nonché trovare potenziali difetti nel codice (e dovrebbero essere eseguiti prima di una revisione del codice umano). Ma il codice viene letto e mantenuto dagli umani e deve prima essere scritto per essere manutenibile. Solo se c'è un motivo per usare un codice meno gestibile, dovrebbe essere scritto in quel modo. Se hai bisogno di un codice complesso o non intuitivo, dovrebbe essere documentato (preferibilmente nel codice) perché il codice è in quel modo e avere commenti utili per i futuri sviluppatori per capire perché e cosa sta facendo il codice.

Idealmente, rifiuta le recensioni di codice che non hanno test appropriati o che hanno un codice troppo complesso senza una buona ragione. Potrebbero esserci motivi commerciali per andare avanti e per questo dovresti valutare i rischi. Se vai avanti con un debito tecnico nel codice, metti immediatamente i biglietti nel tuo sistema di tracciamento dei bug con alcuni dettagli su ciò che deve cambiare e alcuni suggerimenti per cambiarlo.

La verifica manuale della correttezza generale tramite la revisione del codice è tuttavia molto difficile e dispendiosa in termini di tempo, se possibile.

Questo non è in remoto il punto di una revisione del codice. Il modo di pensare a una revisione del codice è di immaginare che ci sia un bug nel codice e devi risolverlo. Con questa mentalità, sfoglia il codice (in particolare i commenti) e chiediti "È facile capire il quadro generale di ciò che sta accadendo in modo da poter restringere il problema?" Se è così, è un passaggio. Altrimenti, è un fallimento. È necessaria almeno ulteriore documentazione, o forse è necessario il refactoring per rendere il codice ragionevolmente comprensibile.

È importante non essere perfezionisti a meno che non si sia sicuri di ciò che il datore di lavoro sta cercando. La maggior parte del codice fa così schifo che potrebbe essere facilmente rifattorizzato 10 volte di seguito, diventando ogni volta più leggibile. Ma il tuo datore di lavoro probabilmente non vuole pagare per avere il codice più leggibile al mondo.

La verifica manuale della correttezza generale tramite la revisione del codice è tuttavia molto difficile e dispendiosa in termini di tempo, se possibile.

Molti anni fa, in realtà, il mio lavoro era fare esattamente questo valutando i compiti degli studenti. E mentre molti hanno fornito una qualità ragionevole con un bug qua e là, ce n'erano due che si sono distinti. Entrambi hanno sempre inviato codice privo di bug. Un codice inviato che ho potuto leggere dall'alto e dal basso ad alta velocità e contrassegnato come corretto al 100% senza sforzo. L'altro codice inviato era un WTF dopo l'altro, ma in qualche modo è riuscito a evitare eventuali bug. Un dolore assoluto da segnare.

Oggi il secondo avrebbe il suo codice rifiutato in una revisione del codice. Se verificare la correttezza è molto difficile e richiede molto tempo, allora questo è un problema con il codice. Un programmatore decente capirebbe come risolvere un problema (richiede tempo X) e prima di consegnarlo a un refattore di revisione del codice in modo che non faccia solo il lavoro, ma ovviamente lo faccia. Ciò richiede molto meno di X in tempo e fa risparmiare molto tempo in futuro. Spesso scoprendo i bug prima ancora di passare alla fase di revisione del codice. Quindi, rendendo la revisione del codice molto più rapida. E sempre in futuro, rendendo il codice più facile da adattare.

Un'altra risposta affermava che il codice di alcune persone poteva essere riformulato 10 volte, diventando ogni volta più leggibile. È solo triste. È uno sviluppatore che dovrebbe cercare un lavoro diverso.

Questo vecchio codice è stato leggermente modificato? (100 righe di codice modificate in una codebase di 10000 righe sono ancora un leggero cambiamento) A volte ci sono vincoli di tempo e gli sviluppatori sono costretti a rimanere in un vecchio e scomodo framework, semplicemente perché una riscrittura completa richiederebbe ancora più tempo ed è fuori budget . + di solito c'è un rischio, che può costare milioni di dollari se valutato in modo errato. Se è un vecchio codice, nella maggior parte dei casi dovrai convivere con esso. Se non lo capisci da solo, parla con loro e ascolta quello che dicono, cerca di capire. Ricorda, può essere difficile da seguire per te, ma perfettamente bene per le altre persone. Prendi la loro parte, vedila dalla loro fine.

Questo nuovo codice è ? A seconda dei vincoli temporali, dovresti sostenere il refactoring il più possibile. Va bene dedicare più tempo alle revisioni del codice, se necessario. Non dovresti cronometrarti per 15 minuti, prendere l'idea e andare avanti. Se l'autore ha trascorso una settimana per scrivere qualcosa, va bene passare 4-8 ore per esaminarlo. Il tuo obiettivo qui è di aiutarli a refactoring. Non devi semplicemente restituire il codice che dice "refactor. Now". Scopri quali metodi possono essere scomposti, prova a trovare idee per introdurre nuove classi, ecc.

Spesso, patch / liste di modifiche "complicate" sono quelle che fanno molte cose diverse contemporaneamente. C'è nuovo codice, codice cancellato, codice refactored, codice spostato, test espansi; rende difficile vedere il quadro generale.

Un indizio comune è che la patch è enorme ma la sua descrizione è minuscola: "Implementa $ FOO".

Un modo ragionevole per gestire una tale patch è chiedere che sia suddiviso in una serie di pezzi più piccoli e autonomi. Proprio come il principio della responsabilità singola afferma che una funzione dovrebbe fare solo una cosa, una patch dovrebbe concentrarsi anche su una sola cosa.

Ad esempio, le prime patch potrebbero contenere refactoring puramente meccanici che non apportano modifiche funzionali, quindi le patch finali possono concentrarsi sull'attuazione e il test effettivi di $ FOO con meno distrazioni e aringhe rosse.

Per funzionalità che richiedono un sacco di nuovo codice, il nuovo codice può spesso essere introdotto in blocchi testabili che non modificano il comportamento del prodotto fino a quando l'ultima patch della serie non chiama effettivamente il nuovo codice (un flag flip).

Per quanto riguarda ciò, in modo tattico, di solito lo dico come un mio problema e quindi chiedo aiuto all'autore: "Ho problemi a seguire tutto ciò che accade qui. Potresti rompere questa patch in passaggi più piccoli per aiutarmi a capire come tutto si adatta insieme?" Talvolta è necessario fornire suggerimenti specifici per i passaggi più piccoli.

Una patch così grande come "Implement $ FOO" si trasforma in una serie di patch come:

1. Introdurre una nuova versione di Frobnicate che richiede un paio di iteratori perché avrò bisogno di chiamarlo con sequenze diverse dal vettore per implementare $ FOO.
2. Cambia tutti i chiamanti esistenti di Frobnicate per utilizzare la nuova versione.
3. Elimina il vecchio Frobnicate.
4. Frobnicate stava facendo troppo. Fattorizza il passo di aggiornamento nel proprio metodo e aggiungi i test per questo.
5. Presenta Zerzify, con i test. Non ancora utilizzato, ma ne avrò bisogno per $ FOO.
6. Implementa $ FOO in termini di Zerzify e il nuovo Frobnicate.

Si noti che i passaggi 1-5 non apportano modifiche funzionali al prodotto. Sono banali da revisionare, anche assicurandosi di avere tutti i test giusti. Anche se il passaggio 6 è ancora "complicato", almeno si concentra su $ FOO. E il registro ti dà naturalmente un'idea molto migliore di come è stato implementato $ FOO (e perché è stato cambiato Frobnicate).

Come altri hanno sottolineato, la revisione del codice non è davvero progettata per trovare bug. Se durante la revisione del codice vengono rilevati dei bug, probabilmente significa che non si dispone di una copertura di test automatizzata sufficiente (ad es. Test di unità / integrazione). Se non c'è abbastanza copertura per convincermi che il codice fa quello che doveva , di solito chiedo altri test e sottolineo il tipo di casi di test che sto cercando e di solito non ammetto il codice nella base di codice che non ha una copertura adeguata .

Se l'architettura di alto livello è troppo complessa o non ha senso, di solito chiamo un incontro con un paio di membri del team per parlarne. A volte è difficile iterare su una cattiva architettura. Se lo sviluppatore era un principiante, di solito mi assicuro che passiamo in rassegna i loro pensieri in anticipo invece di reagire a una cattiva richiesta di pull. Questo di solito è vero anche con sviluppatori più esperti se il problema non ha una soluzione ovvia che sarà probabilmente scelta.

Se la complessità è isolata al livello del metodo che di solito può essere corretto in modo iterativo e con buoni test automatizzati.

Un ultimo punto. Come revisore devi decidere se la complessità del codice è dovuta a complessità essenziale o accidentale . La complessità essenziale riguarda le parti del software che sono legittimamente difficili da risolvere. La complessità accidentale si riferisce a tutte le altre parti del codice che scriviamo che è troppo complesso senza motivo e potrebbe essere facilmente semplificato.

Di solito mi assicuro che il codice con una complessità essenziale sia veramente questo e non possa essere ulteriormente semplificato. Miro anche a una maggiore copertura dei test e una buona documentazione per queste parti. La complessità accidentale dovrebbe essere quasi sempre ripulita durante il processo di richiesta pull perché sono la maggior parte del codice che trattiamo e possono facilmente causare incubo di manutenzione anche a breve termine.

Come sono i test? Dovrebbero essere chiari, semplici e facili da leggere con idealmente una sola affermazione. I test dovrebbero documentare chiaramente il comportamento previsto e i casi d' uso del codice.

Se non è ben testato, è un buon posto per iniziare la revisione.