Cosa fai quando la revisione del codice è troppo difficile?

OK, quindi molta revisione del codice è abbastanza ordinaria. Ma a volte ci sono cambiamenti che incidono ampiamente sul codice complesso e fragile esistente. In questa situazione, il tempo necessario per verificare la sicurezza delle modifiche, l'assenza di regressione, ecc. È eccessivo. Forse anche superare il tempo necessario per lo sviluppo stesso.

Cosa fare in questa situazione? Unisci e speri che non ti sfugga nulla? (Non propugnarlo!) Fai il meglio che puoi e cerca solo di individuare eventuali difetti evidenti (forse questa è la maggior parte della revisione del codice che dovrebbe mirare comunque?) Unire e testare in modo molto approfondito come un'alternativa migliore della revisione del codice?

Questo non è specificamente una domanda se il test dovrebbe essere fatto come parte di una revisione del codice. Questa è una domanda che pone quali sono le migliori opzioni nella situazione descritta, in particolare con una scadenza pressante, nessuna suite completa di test unitari disponibili o test unitari non praticabili per il codice frammentato che è cambiato.

EDIT: ho l'impressione che alcune delle risposte / dei commenti finora abbiano raccolto la mia frase "ampiamente impatto", e forse ho preso questo per significare che il cambiamento ha coinvolto un gran numero di righe di codice. Posso capire che questa è l'interpretazione, ma non era proprio mia intenzione. Per "impatto generale", intendo ad esempio che il potenziale di regressione è elevato a causa dell'interconnessione della base di codice o della portata degli effetti knock-on, non necessariamente che il cambiamento stesso sia grande. Ad esempio, uno sviluppatore potrebbe trovare un modo per correggere un bug con una singola linea chiamando una routine di alto livello esistente che collega in cascata le chiamate a molte routine di livello inferiore. Testare e verificare che la correzione dei bug ha funzionato è facile. Convalidare manualmente (tramite revisione del codice) l'impatto di tutti gli effetti knock-on è molto più difficile.

La premessa della domanda è, francamente, sorprendente. Supponiamo che ci sia una grande modifica al codice fragile e complesso e che non ci sia abbastanza tempo per esaminarlo correttamente . Questo è l' ultimo codice che dovresti dedicare meno tempo alla revisione! Questa domanda indica che hai problemi strutturali non solo nel tuo codice stesso, ma nella tua metodologia di gestione del cambiamento.

Quindi, come affrontare questa situazione? Inizia non entrarci in primo luogo:

• Identificare le fonti di complessità e applicare rifatturazioni accurate, fortemente riviste e corrette per aumentare il livello di astrazione. Il codice dovrebbe essere comprensibile per un nuovo dipendente appena uscito dal college che sa qualcosa sul tuo dominio aziendale.

• Identificare le fonti di fragilità; questo potrebbe essere mediante la revisione del codice stesso, esaminando la cronologia delle correzioni di bug nel codice e così via. Determinare quali sottosistemi sono fragili e renderli più robusti . Aggiungi logica di debug. Aggiungi affermazioni. Crea un'implementazione lenta ma ovviamente corretta dello stesso algoritmo e nella tua build di debug, esegui entrambi e verifica che siano d'accordo. Nella build di debug, è possibile che si verifichino situazioni rare più frequentemente. (Ad esempio, creare un allocatore di memoria che sposta sempre un blocco sulla riallocazione o alloca sempre un blocco alla fine di una pagina o qualsiasi altra cosa.) Rendere robusto il codice di fronte alle modifiche al suo contesto. Ora non hai più un codice fragile; ora hai il codice che trova i bug, piuttosto che causare i bug.

• Scrivi una suite di test automatizzati. Ovviamente.

• Non apportare grandi cambiamenti. Apporta una serie di piccole modifiche mirate, ognuna delle quali può essere vista come corretta.

Ma fondamentalmente, il tuo scenario è "ci siamo scavati in un buco di debito tecnico e ogni cambiamento complesso e non visto ci scava più in profondità; cosa dovremmo fare?". Cosa fai quando ti trovi in ​​quel buco? Smetti di scavare . Se hai così tanto debito che non sei in grado di svolgere attività di base come rivedere il codice a vicenda, allora devi smettere di accumulare più debito e passare il tempo a ripagarlo.

Uno degli obiettivi principali di una revisione del codice è aumentare la qualità e fornire un codice affidabile . Robusto, perché 4 occhi di solito individuano più problemi di 2. E il recensore che non ha scritto il codice aggiuntivo ha maggiori probabilità di contestare ipotesi (potenzialmente sbagliate).

Evitare le revisioni tra pari nel tuo caso contribuirebbe solo ad aumentare la fragilità del codice. Naturalmente, il rafforzamento dei test con una suite di test solida e ripetibile potrebbe sicuramente migliorare la qualità. Ma dovrebbe essere complementare alla revisione tra pari, non una sostituzione .

Penso che la complessità debba essere compresa e padroneggiata e la revisione inter pares è l'occasione per condividere le conoscenze e raggiungere questo obiettivo. L'investimento che fai per avere più persone a comprendere la forza e la debolezza del fragile codice, contribuirà a renderlo migliore nel tempo.

Una citazione per concludere:

"Se vuoi andare veloce, vai da solo. Se vuoi andare lontano, vai insieme"

Benvenuti nel mondo dello sviluppo di software legacy.

Hai centinaia di migliaia, milioni, 10 milioni di righe di codice.

Queste righe di codice sono preziose, in quanto producono un flusso di entrate e la loro sostituzione non è fattibile.

Il modello di business si basa sulla leva di tale base di codice. Quindi la tua squadra è piccola, la base di codice è grande. È necessario aggiungere funzionalità a per convincere le persone ad acquistare una nuova versione del codice o per soddisfare i clienti esistenti.

In un mondo perfetto, la tua enorme base di codice è l'unità testata sul wazoo. Non vivi in ​​un mondo perfetto.

In un mondo meno perfetto, hai il budget per riparare il tuo debito tecnico: suddividere il codice in unità testabili, eseguire test di integrazione approfonditi e iterare.

Questo, tuttavia, sta pagando il debito senza produrre nuove funzionalità. Il che non corrisponde al caso aziendale di "raccogliere profitti dal codice esistente, modificandolo al fine di generare incentivi per l'aggiornamento".

Potresti prendere enormi blocchi di codice e riscriverlo usando tecniche più moderne. Ma ovunque interagirai con il codice esistente, esporrai possibili punti di interruzione. L'hacking nel sistema di cui ti sei liberato ha effettivamente compensato una stranezza in un sottosistema che non hai riscritto. Sempre.

Quello che puoi fare è agire con attenzione. È possibile trovare una parte del codice che si comprende effettivamente e il cui comportamento e l'interazione con il resto del sistema è ben compreso. Puoi modernizzarlo, aggiungendo unit test e rendendo ancora più chiaro il suo comportamento.

Quindi trova le parti del resto dell'app che interagiscono principalmente con essa e attaccale una alla volta.

Mentre lo fai, puoi migliorare il sottosistema, aggiungendo funzionalità che i clienti sono disposti a pagare.

In breve, questa è l'arte del possibile: apportare modifiche senza rompere le cose che forniscono un caso aziendale.

Ma questa non è la tua domanda. La tua domanda è: "Sto facendo qualcosa di enorme e che probabilmente romperà le cose, e come seguo le migliori pratiche?"

Quando fai qualcosa di enorme, è vero che se vuoi farlo in modo affidabile finisci per spendere più sforzo a rintracciare i bug e risolverli di quanto tu non scriva. Questa è la regola generale dello sviluppo del software: scrivere cose è facile, farlo funzionare in modo impeccabile è difficile.

Probabilmente hai un business case sospeso sopra la testa, in cui hai promesso ad alcuni stakeholder che questo enorme cambiamento si verificherà. Ed è "fatto", quindi ricevi un respingimento dicendo "no, non è fatto, sembra solo mi piace".

Se hai il potere e il budget, spendi effettivamente lo sforzo per generare la sicurezza che il cambiamento funzioni o semplicemente respingi il cambiamento. Questa sarà una questione di laurea, non gentile.

Se non hai molta potenza, ma ne hai ancora, prova a insistere sul fatto che il nuovo sistema è testabile dall'unità . Se si riscrive qualche sottosistema, insistere sul fatto che il nuovo sottosistema è composto da piccole parti con comportamento ben specificato e test unitari intorno a loro.

Quindi c'è il caso peggiore. Andare più in profondità nel debito. Prendi in prestito contro il futuro del programma avendo più codice che è fragile e più bug al fine di ottenere la funzionalità ora e dannatamente le conseguenze. Esegui un QA basato su sweep per trovare i problemi peggiori e ignorare il resto. Questa è in realtà a volte la risposta giusta dal punto di vista del business, in quanto è più economica ora. L'indebitamento per generare profitti è una valida strategia aziendale, soprattutto se la compensazione del debito tramite fallimento (abbandono del codice) è sul tavolo.

Un grosso problema è che raramente gli incentivi dei proprietari dell'azienda sono allineati con i decisori e i programmatori. Si tende a fare molta pressione per "consegnare", e farlo generando un debito tecnico quasi invisibile (per i propri superiori) è una grande strategia a breve e talvolta a medio termine. Anche se i tuoi superiori / parti interessate sarebbero meglio serviti non creando tutto quel debito.

Risolvi i problemi più grandi che stanno causando la revisione del codice troppo difficile.

Quelli che ho notato finora:

1. Nessuna suite di test unitari
2. Unioni complesse di codice che potrebbero essere evitate da una struttura del codice più sensibile e dalla delega delle funzioni di codifica
3. Un'apparente mancanza di architettura rudimentale

1. È possibile inviare nuovamente la revisione del codice e dire allo sviluppatore di suddividerla in changeset più piccoli e più incrementali e inviare una revisione del codice più piccola.

2. È ancora possibile verificare la presenza di odori di codice, schemi e antimodelli, standard di formattazione del codice, principi SOLIDI, ecc. Senza necessariamente esaminare tutti i dettagli del codice.

3. È ancora possibile eseguire ispezioni del codice tattico per una corretta convalida dell'input, blocco / gestione thread, possibili eccezioni non gestite, ecc. A un livello dettagliato, senza necessariamente comprendere l'intenzione generale dell'intero gruppo di modifiche.

4. Puoi fornire una valutazione delle aree di rischio complessive che ritieni possano essere influenzate dal codice e chiedere allo sviluppatore di confermare che queste aree di rischio sono state testate in unità (o chiedere di scrivere test di unità automatizzati e di inviarle anche per la revisione ).

In questa situazione, il tempo necessario per verificare la sicurezza delle modifiche, l'assenza di regressione, ecc. È eccessivo.

Le revisioni del codice non dovrebbero mirare principalmente alla correttezza. Sono qui per migliorare la leggibilità del codice, la manutenibilità e l'aderenza agli standard del team.

Trovare bug di correttezza durante una revisione del codice è un buon sottoprodotto di farli, ma uno sviluppatore dovrebbe assicurarsi che il loro codice funzioni perfettamente (inclusa la non regressione) prima di inviarlo per la revisione .

La correttezza dovrebbe essere integrata fin dall'inizio. Se uno sviluppatore non è in grado di realizzarlo, abbina il programma o trova un piano con l'intero team ma non lo considera come qualcosa che puoi aggiungere come ripensamento.

Se pensi che la revisione del codice sia troppo difficile, perché ha cambiato il codice fragile che è quasi impossibile da cambiare senza romperlo, allora hai un problema. Ma il problema non riguarda la revisione del codice. Il problema non riguarda i test unitari, poiché non è possibile testare il codice fragile! Se il tuo codice fosse unitamente testabile, sarebbe stato suddiviso in piccole unità indipendenti, ognuna delle quali può essere testata e funziona bene insieme, ed è esattamente quello che non hai!

Quindi hai un mucchio di codice spazzatura (noto anche come "debito tecnico"). La cosa peggiore che puoi fare è iniziare a riparare quel mucchio di codice spazzatura e non finire il lavoro perché in questo modo otterrai un mucchio ancora più grande di codice spazzatura. Quindi la prima cosa è convincere il tuo management ad acquistare per risolverlo e per finire il lavoro. Oppure no. In tal caso, non lo tocchi.

Quando lo risolvi, estrai un'unità dal codice, lo trasformi in qualcosa che ha un comportamento ben definito e ben documentato, scrivi test di unità per quell'unità, ripassa il codice e prega che nulla si rompa. E poi fai lo stesso con l'unità successiva, e così via.

La parte difficile arriva quando si imbattono in bug. Il tuo nido di codice di ratti farà le cose sbagliate in alcuni casi perché le cose sono così fragili e complicate, le cose andranno male. Man mano che estraete le unità, il codice rimanente diventerà più chiaro. (Ho avuto un caso in cui dopo un po 'di refactoring, una funzione è iniziata con "if (condition1 && condition2 && condition3) crash ();" che era esattamente il comportamento prima del refactoring, solo più chiaro. Ho quindi eliminato quella riga :-) Vedrai comportamento strano e indesiderato chiaramente, in modo da poterlo risolvere. D'altra parte, è lì che devi cambiare il comportamento del codice esistente, quindi è necessario farlo con attenzione).

Sfortunatamente, non c'è davvero molto che puoi fare al riguardo nella revisione del codice oltre a prendere un'altra tazza di caffè. La vera soluzione a questo problema è quella di affrontare il debito tecnico che hai accumulato: design fragile, mancanza di test. Spero che tu abbia almeno una sorta di QA funzionale. Se non lo hai, allora preghi sempre per alcune ossa di pollo.

Se non ti accontenti di spedire con software difettoso / non funzionante e risolverlo in un secondo momento, lo sforzo V&V DOVREBBE essere più lungo dello sforzo di sviluppo!

Se il codice esistente è fragile, allora una prima domanda è "dovresti anche cambiarlo?" La direzione deve fare una richiesta per stabilire se il costo / rischio di riprogettazione e reimplementazione di questo codice è maggiore del costo / rischio di sistemare il mucchio traballante di spazzatura. Se è una tantum, potrebbe essere più semplice semplicemente rattopparlo. Se in futuro ci saranno probabilmente più cambiamenti necessari, prendere il colpo ora per evitare più dolore in futuro potrebbe essere una decisione migliore. Devi sollevare questo problema con il tuo management, perché dare ai tuoi manager buone informazioni fa parte del tuo lavoro. Devono prendere quella decisione, perché è una decisione strategica che è al di sopra del tuo livello di responsabilità.

In base alla mia esperienza, ti consiglio vivamente di coprire il tuo codice con una buona quantità di test, sia di unità che di integrazione, PRIMA di apportare qualsiasi modifica al sistema in questione. È importante ricordare che al giorno d'oggi esiste un ottimo numero di strumenti a tale scopo, indipendentemente dalla lingua con cui stai sviluppando.

Inoltre, c'è lo strumento di tutti gli strumenti per creare i tuoi test di integrazione. Sì, sto parlando di container e specialmente di Docker e Docker Compose . Ci offre meravigliosamente un modo per configurare rapidamente un ambiente applicativo complesso, con infrastrutture (database, mongodb, server di code ecc.) E applicazioni.

Gli strumenti sono disponibili, usali! :)

Non so perché non sia stato ancora menzionato, ma questi 2 sono i pezzi più importanti:

• Hai diviso la lista delle modifiche in più liste delle modifiche più piccole, che poi rivedi una dopo l'altra. *
• Se la revisione di un elenco modifiche non determina una decisione secondo cui l'elenco modifiche sembra essere valido, ovviamente si rifiuta il cambiamento.

* Esempio: si sostituisce la libreria A con la libreria B. Un elenco di modifiche introduce la libreria B, vari elenchi di modifiche sostituiscono l'utilizzo di A con B pezzo per pezzo (ad esempio un elenco di modifiche per modulo) e l'ultimo elenco di modifiche elimina la libreria A.

Fare il meglio possibile e cercare solo di individuare eventuali difetti evidenti (forse questa è la maggior parte della revisione del codice che dovrebbe mirare comunque)?

Non sottovalutare il valore potenziale delle revisioni del codice. Possono essere bravi a rilevare i bug:

• Trova i bug che sarebbero difficili da rilevare durante i test
• Trova i bug che sarebbero difficili da identificare / correggere durante i test

Sono utili anche per altri motivi:

• Aiuta a formare in modo incrociato i membri del team
• Aiuta a garantire che il codice soddisfi altre metriche di qualità, ad esempio aiuta a garantire che sia comprensibile e gestibile e non solo privo di bug

Cosa fare in questa situazione?

Nel caso migliore / ideale, passare l'ispezione del codice non significa semplicemente "nessun bug evidente": significa "ovviamente nessun bug" (anche se ovviamente vorrai anche testarlo).

Se non è possibile verificare la nuova base di codice tramite l'ispezione del codice, sarà necessario eseguire test più approfonditi sulla "scatola nera". Potresti essere abituato a un ciclo di sviluppo in cui metti il ​​codice in produzione dopo che ha superato l'ispezione, ma se non riesce a "passare l'ispezione", non puoi "metterlo in produzione" e ha bisogno di un ciclo più lungo: ad esempio test di integrazione , test di sistema, test alfa, test di accettazione, beta test, ecc.

nessuna suite completa di unit test disponibili o unit test non praticabili per il codice frammentato che è stato modificato

E i test di integrazione, sistema e accettazione?

Ad ogni modo dovresti probabilmente dire al project manager e al product manager che il codice è quasi sicuramente difettoso, con un numero sconosciuto di bug; e che "otterranno ciò che ispezionano" anziché semplicemente "ciò che si aspettano", ovvero che la qualità del codice non è migliore del loro test (perché la qualità del codice non è stata e non può essere garantita dall'ispezione del codice) .

Dovrebbero possibilmente inoltrare quel messaggio al cliente o agli utenti, quindi eseguono il beta test (se sono disposti ad essere dei primi ad adottare) o utilizzare la versione precedente fino a quando la nuova versione non è fuori dalla beta (se non lo sono).

Un sacco di codice viene scritto e unito senza una corretta revisione del codice. Può funzionare C'è un motivo per cui si chiama odore di codice non "codice rotto" o qualcosa in tal senso. La mancanza di revisione del codice è un segnale di avvertimento, non un presagio di sventura.

La soluzione a questo problema è che non esiste una soluzione adatta a tutti i casi che possiamo includere in una risposta in stile StackExchange. È opinione forte della comunità di sviluppo software che la revisione del codice sia una "best practice" cruciale e in questo caso viene ignorata. Il tuo sviluppo non è più nello stretto canale di "seguire tutte le migliori pratiche". Dovrai trovare la tua strada.

Che cos'è comunque una "best practice"? Quando si arriva fin qui, è un insieme di pratiche che le persone generalmente pensano che migliorino il codice. Fanno il codice giusto? Diamine no! Internet è disseminato di storie di aziende che hanno seguito le "migliori pratiche" e si sono inceppate. Forse un punto di vista migliore delle "migliori pratiche" è che sono le soluzioni "fuoco e dimentica" del mondo del software. Non posso sapere nulla della tua azienda, del tuo progetto, del tuo team ed essere in grado di annullare le "migliori pratiche" come elementi che ti aiuteranno. Sono i consigli generali "non fare del male".

Ti sei chiaramente discostato da questo piano. Fortunatamente, lo riconosci. Buon lavoro! Dicono che la conoscenza è metà della battaglia; in tal caso, la consapevolezza è ben oltre la metà! Adesso è necessaria una soluzione. Dalla tua descrizione, è chiaro che l'ambiente aziendale in cui ti trovi si è evoluto a un punto in cui il noioso consiglio di "vai a fare la revisione del codice, è la migliore pratica" non lo taglierà. Per questo, raccomando una regola chiave che uso quando si tratta delle migliori pratiche del software:

Nessuna best practice di sviluppo software supera le esigenze aziendali.

Francamente, stanno pagando la tua busta paga e la sopravvivenza del business è in genere molto più importante della qualità del software. Non ci piace ammetterlo, ma il software perfettamente scritto è inutile se è intrappolato nel corpo di un'azienda che muore dai suoi sforzi per sostenere quel software perfettamente scritto.

Allora dove vai? Segui la scia della forza. Hai sottolineato che, per qualche motivo non dichiarato, è irragionevole sottoporsi a una revisione del codice per alcune attività. Nella mia esperienza, quella ragione è sempre temporale. È sempre o "non abbastanza tempo" o "non abbastanza denaro per far scorrere i salari mentre passi il tempo". Questo è business; va bene. Se fosse facile, tutti lo farebbero. Segui la scia della forza verso l'alto e trova la direzione che è in grado di aiutarti a capire perché una revisione del codice non è un'opzione. La lingua è difficile e molto spesso un decreto uscirà dalla direzione superiore e si distorcerà. La soluzione al tuo problema potrebbe essere nascosta in quella distorsione.

La risposta a questo è, necessariamente, uno scenario specifico. È come cercare di prevedere se il lancio di una moneta sarà testa o croce. Le migliori pratiche dicono di capovolgerlo 100 volte e l'aspettativa sarà di circa 50 teste e 50 code, ma non hai tempo di capovolgerlo 1 volta. È qui che contano i dettagli della tua situazione. Sapevi che una moneta generalmente atterrerà nello stesso orientamento in cui è stata lanciata dal 51% circa delle volte? Ti sei preso il tempo di osservare da che parte era la moneta prima di lanciare? Potrebbe fare la differenza.

Una soluzione generale che potrebbe essere disponibile per te è quella di cercare di trovare un modo per elaborare il processo di revisione del codice e renderlo uno sforzo a costi molto bassi. Gran parte del costo di un processo di revisione del codice è che tutti sono dedicati al 100% alla revisione del codice mentre lo stai facendo. Questo deve essere il caso perché, una volta effettuata la revisione del codice, il codice viene benedetto. Forse puoi inserire il codice in un altro ramo ed eseguire la revisione del codice in parallelo con lo sviluppo sul trunk principale. O forse puoi anche configurarlo in modo che il software faccia il test per te. Forse ti trovi in ​​un ambiente aziendale in cui i tuoi clienti possono eseguire il "nuovo" codice in parallelo con il vecchio e farli confrontare i risultati. Questo trasforma i clienti in un sacco di dispositivi per la creazione di casi d'uso.

Una chiave per tutti questi "maybes" in esecuzione è che dovresti sforzarti di trasformare facilmente il tuo codice in pezzi. Potresti essere in grado di "provare" parti del codice senza fare affidamento su una revisione formale del codice utilizzandole in progetti meno critici. È più facile farlo se le modifiche sono in pezzi più piccoli, anche se la somma totale è troppo grande per la revisione tra pari.

In generale, cerca soluzioni specifiche per il tuo progetto, la tua azienda, il tuo team. La risposta generale era "buone pratiche". Non li stai usando, quindi questa volta dovresti cercare altre soluzioni personalizzate per questo problema. Sono affari. Se tutto fosse andato come ci aspettavamo continuamente, le IPO sarebbero molto più facili da assegnare ai valori, no?

Se sostituire una revisione del codice è una lotta, ricorda che non c'è mai stato un singolo pezzo di codice che ha dimostrato di funzionare in una revisione del codice. * Tutto ciò che fa una revisione del codice è darti fiducia nel codice e un'opportunità per apportare correzioni prima che diventino un problema. Entrambi questi preziosi prodotti di una revisione del codice possono essere acquisiti con altri mezzi. La revisione del codice ha un valore riconosciuto per essere particolarmente brava.

* Bene, quasi: il microkernel L4 ha ricevuto una revisione del codice qualche tempo fa da un sistema di prova automatizzato che dimostra che il suo codice, se compilato da un compilatore C ++ conforme, farà esattamente ciò che dice la documentazione.

Come sottolinea @EricLippert nella sua eccellente risposta, questo tipo di cambiamento richiede più attenzione, non meno . Se ti rendi conto che un cambiamento a cui stai lavorando diventerà tale cambiamento, ci sono alcune strategie che potrebbero aiutare:

• Impegnarsi frequentemente nel controllo della versione. La revisione può progredire su base commit-by-commit e potrebbe essere più comprensibile in caso di commit minori.
• Assicurati di commentare i motivi di ogni modifica nel modo più chiaro possibile.
• Se del tutto plausibile, utilizzare la programmazione di coppia per questo tipo di modifica. Avere tre serie di occhi sul problema piuttosto che 2 può aiutare a evitare problemi che potrebbero essere persi normalmente, e avere una coppia mentre lavori può aiutarti a migliorare qualsiasi commento sul codice che pensavi fosse ovvio ma che risulta essere meno ovvio di quanto pensassi, che a sua volta aiuterà il revisore in seguito. L'aiuto nella (a) riduzione degli errori durante lo sviluppo e (b) nel miglioramento della documentazione potrebbe effettivamente significare che meno ore di lavoro sono dedicate a questo, nonostante il coinvolgimento di più persone.

Altre risposte riguardano come sei arrivato a questo punto. Molti di loro danno alcuni suggerimenti per porre rimedio alla situazione, ma vorrei dare la mia risposta per dare la risposta breve.

Cosa fare quando le recensioni del codice sono "troppo difficili?"

1. Torna al ramo del codice della linea principale
2. Scrivi test per la funzionalità che hai refactored (ad es. Test funzionali)
3. Fai passare i test
4. Unisci i test nel codice "difficile da testare"
5. I test superano ancora?

sì

Siete stati grandi sviluppatori! I gatti tornano per tutti!

(o per coloro che non sono cresciuti guardando " The Simpsons " sulla televisione americana: se i test stanno superando, salta il tentativo di guardare le differenze e chiedi allo sviluppatore di guidarti in un tour delle modifiche)

No

Continua a eseguire il refactoring e ad aggiungere la copertura del test fino al superamento dei test.

Come una moltiplicazione, la revisione del codice dà zero risultati se applicata a zero. In questo caso non aumenta il valore, mentre nella maggior parte degli altri casi lo farebbe.

Il codice con cui devi lavorare è troppo mal progettato per beneficiare del processo di revisione del codice durante l'ulteriore sviluppo. Utilizzare il processo di revisione del codice per riformattare o ri-svilupparlo.

Potrebbe anche essere che il codice sia ancora sopportabile ma l'attività non è buona. È troppo ampio e avrebbe dovuto essere fatto con incrementi più piccoli.