L'analisi statica dovrebbe essere integrata con la revisione del codice? [chiuso]

Gli strumenti che elenchi non hanno nulla a che fare con le revisioni del codice. Sono lì esattamente per consentire ai revisori di concentrarsi su argomenti più utili.

Le revisioni del codice sono per cose importanti che non possono essere automatizzate : utilizzando un modello di progettazione quando un altro corrisponde meglio, la codifica eccessiva del codice chiaro o sottodelocumentazione poco chiara, non utilizzando le caratteristiche del linguaggio che possono rendere codice più corto e più leggibile. Tutte queste cose sono "troppo intelligenti" per una macchina: un programma, non importa quanto sia sofisticato, non sarà in grado di dire se la vostra applicazione di pattern di fabbrica astratta è una buona idea in un dato contesto o no. Ecco perché le revisioni del codice vengono eseguite da persone, spesso sviluppatori più esperti.

Gli argomenti menzionati durante le revisioni del codice sono spesso soggettivi . Uno sviluppatore dirà che questo metodo specifico dovrebbe essere diviso in due. Un altro altrettanto esperto considererà che il metodo va bene e fa esattamente una cosa. Un recensore troverà una dichiarazione goto terribile; il suo collega potrebbe scoprire che, in questo caso particolare, goto va bene e non può essere rimosso senza che ciò comporti un codice meno leggibile.

Gli strumenti di stile, d'altra parte, sono l'archetipo dell'automazione delle regole puramente oggettive, di base, anche a volte stupide . La linea 273 è troppo lunga. Hai dimenticato una lettera maiuscola. E qui, manca uno spazio. E qui, ho trovato due righe vuote invece di una. Boooring.

Non perdere tempo a nessuno durante le revisioni del codice. Se c'è una guida di stile nel tuo progetto, usa il controllo dello stile (come pep8 ) ma eseguilo automaticamente tramite il gancio di pre-commit. Spazio mancante? Nessun impegno per te, signore. Una riga vuota contiene spazi bianchi? Per favore rimuovilo se vuoi il tuo codice nel controllo della versione.

In effetti:

• Poiché le regole sono obiettive e semplici, non c'è nulla da discutere durante una revisione del codice. C'è spazio bianco in una riga vuota. Quindi rimuovilo. Cosa ti piacerebbe raccontare a riguardo durante una revisione del codice?

• Peggio, può portare a discussioni che sono quasi costruttive. Per alcuni, le recensioni di codice diventerebbero un'opportunità per discutere i meriti del loro stile preferito , perché, francamente, tutti sanno che due spazi sono meglio di quattro, e ora, la revisione del codice si concentra su "Dovrebbe cambiamo il nostro stile di codice e riscriviamo l'intero codice base per utilizzare due spazi anziché quattro ". Evita questo a tutti i costi.

Il rimanente, il materiale troppo complicato per una macchina, è per le revisioni del codice, permettendo ai revisori di concentrarsi su cose che contano davvero.

Il controllo automatico, sarebbe il controllo dello stile, la compilazione, i test, l'analisi statica o la prova formale, dovrebbe essere, beh, automatizzato. Dove dovrebbe essere nel processo di integrazione continua è un argomento diverso. Controlli brevi e veloci, come il controllo dello stile, possono essere inseriti direttamente in un hook pre-commit per evitare qualsiasi codice non conforme nel codice base. Controlli lunghi, come l'analisi statica, verranno solitamente eseguiti durante la compilazione.

Ricorda, se hai un argomento che:

1. Non ha una risposta diretta, la risposta è basata sull'esperienza personale e sulle ipotesi formulate,
2. Risultati non binari "bene, può essere A, ma B può essere accettato qui, mentre C sembra un po 'problematico, ma sarà un'ottima soluzione se questo fosse" risposte in stile,
3. Non può essere automatizzato anche con le applicazioni più sofisticate,
4. Non può essere facilmente portato su un altro contesto,
5. È incentrato sulla qualità del codice, sulla leggibilità, sull'espressività e sulla manutenibilità,

recensioni di codice potrebbero essere un buon posto per questo. D'altra parte, se il soggetto:

1. È puramente oggettivo e senza ambiguità,
2. Risultati in una risposta binaria, spesso basata su una metrica,
3. Può essere automatizzato (a volte richiede molto di lavoro e ricerca),
4. Si applica a tutte le situazioni nello stesso gruppo,
5. È incentrato sulla qualità del codice, sulla leggibilità, sull'espressività e sulla manutenibilità,

i hook pre-commit o la build sono posti molto migliori di una revisione del codice.

Ulteriori letture:

• Come impostare qualcosa come un server di integrazione che misura la qualità del codice e rifiuta il codice se il punteggio è inferiore un certo numero?

• Linters rock, ma sono lenti

Questa risposta è basata su due presupposti. Innanzitutto, stai utilizzando uno strumento di analisi statica che è più di un controllo di stile ( PMD e / o FindBugs anziché Checkstyle , ad esempio). In secondo luogo, lo strumento è stato configurato correttamente in relazione agli errori rilevati e alla gravità dell'errore per il processo o il prodotto specificato.

Sì, gli strumenti di analisi statica progettati per trovare errori dovrebbero far parte del processo di revisione del codice. Più in generale, è necessario eseguire uno strumento di analisi statico ed esaminare i risultati come parte di una revisione del codice, prima di inserire il codice in un ramo utilizzato da altri sviluppatori.

Prima della revisione del codice, lo sviluppatore deve eseguire e correggere i problemi rilevati dallo strumento di analisi statica, con eventuali risultati rivisti e eventuali risultati importanti corretti. Quindi, dovrebbero essere rieseguiti sul codice per produrre errori rimanenti. Questo elenco dovrebbe far parte della revisione del codice. Ciò consentirà ai revisori del codice umano di concentrarsi su problemi che non riescono a trovare, o forse di prestare particolare attenzione alle aree del codice contrassegnate dallo strumento (doppio controllo dei falsi positivi).

Idealmente, hai utilizzato lo strumento sin dall'inizio del progetto. Se no, tuttavia, e ci sono un gran numero di risultati, questi dovrebbero essere rivisti e disposti, cosa che non sarebbe fatta come parte di una revisione del codice. A questo punto, farei l'esecuzione della parte dello strumento del processo di integrazione o di integrazione continua e ogni build dovrebbe ridurre il numero di errori. Gli sviluppatori dovrebbero usare queste informazioni per aiutare lasciare il codice che toccano in uno stato migliore di quello che hanno trovato durante il refactoring o lo sviluppo. Ovviamente, l'uso dell'elenco durante una revisione del codice sarebbe utile anche per identificare potenziali problemi che dovrebbero essere corretti per garantire che il codice sia migliore di prima.