Come posso rivedere il mio codice? [chiuso]

Sto lavorando a un progetto da solo e devo mantenere il mio codice. Di solito la revisione del codice non viene eseguita dall'autore del codice, quindi il revisore può guardare il codice con occhi nuovi - tuttavia, non ho un tale lusso. Quali pratiche posso utilizzare per rivedere in modo più efficace il mio codice?

Prima di tutto, fai uso degli strumenti per controllare il più possibile. I test (supportati da una copertura del codice ragionevole) daranno una certa sicurezza della correttezza del codice. Gli strumenti di analisi statica possono catturare molte cose delle migliori pratiche. Ci saranno sempre dei problemi su cui hai bisogno degli occhi umani per determinare se e non farai mai un buon lavoro rivedendo le tue cose come qualcun altro, ci sono alcune cose che puoi fare per aiutare comunque

• verificare che i test esistano e superino (possibilmente avere una copertura test target, anche se in alcuni casi potrebbe essere necessario interromperlo, ma si dovrebbe essere in grado di giustificare il perché)
• controlla che l'analisi statica passi (ci saranno anche falsi negativi qui, ma va bene finché puoi giustificare il motivo per cui allora va bene sopprimerli)
• mantenere un elenco di controllo di ulteriori elementi da controllare in fase di revisione (aggiungere idealmente questo come nuove regole di analisi statica se possibile) assicurarsi di controllare tutto ciò che la SA non può controllare, ad esempio se i commenti sono ancora validi, le cose sono denominate in modo appropriato (la denominazione delle cose è ovviamente, uno dei 2 problemi difficili noti all'informatica)
• se viene identificato un errore, verificare se la causa è sistemica e verificare perché non è stata rilevata in test o recensioni precedenti

Questo, ovviamente, è utile quando si stanno rivedendo anche altri codici

Dai un'occhiata al sito di scambio di stack di code review . È per la condivisione del codice dai progetti su cui stai lavorando per la revisione tra pari :

Code Stack Stack Exchange è un sito di domande e risposte per la ricerca di peer review del codice. Stiamo lavorando insieme per migliorare le competenze dei programmatori di tutto il mondo prendendo il codice di lavoro e migliorandolo.

Se stai cercando feedback su uno specifico pezzo di codice funzionante dal tuo progetto nelle seguenti aree ...

• Best practice e utilizzo del modello di progettazione
• Problemi di sicurezza
• Prestazione
• Correttezza in casi imprevisti

È inoltre possibile utilizzare strumenti di analisi statica del codice per rilevare determinati tipi di problemi, ma in alcuni casi genereranno falsi allarmi e non possono suggerire come migliorare il design.

Ho sviluppato diverse persone totalmente diverse nella mia testa. Uno di loro non è nemmeno un programmatore! Stiamo chattando, discutendo le ultime notizie e rivedendo il codice reciproco.

Consiglio vivamente il mio approccio.

ps Non sta scherzando.

Concordo con l'opinione di JK-S che la revisione da parte di una sola persona non sia efficace come la revisione da parte di 2 persone. tuttavia puoi provare a trarne il meglio:

revisione a breve termine (poco dopo la produzione del codice)

Sto usando git come repository locale. Ogni volta che ho terminato una funzione o corretto un bug, trasferisco le modifiche al repository.

Prima di effettuare il check-in, confronto ciò che ho modificato nel mio codice e ripenso:

• variabili / metodo / nomi di classe riflettono ancora a cosa servono?

revisione a lungo termine (6 mesi dopo la produzione del codice)

Mi chiedo:

• posso descrivere in un colpo solo cosa fa una classe / metodo / variabile?
• quanto è facile usare una classe in isolamento (senza le altre classi) o scrivere un unittest per?

Innanzitutto, metti da parte il codice per tutto il tempo in cui è pratico. Lavora su qualcos'altro, qualche altra parte di codice. Anche dopo una giornata, rimarrai stupito da ciò che troverai.

Secondo, documenta il tuo codice. Molti programmatori odiano documentare il loro codice, ma costringiti a sederti e scrivere documentazione, come usare il codice e come funziona. Guardando il tuo codice in modo diverso, troverai errori.

È stato detto che la vera padronanza di una materia è la capacità di insegnarla a qualcun altro. Con la documentazione stai cercando di insegnare a qualcun altro il tuo codice.

Trasforma questa tecnica di debug in una tecnica di revisione del codice: http://en.wikipedia.org/wiki/Rubber_duck_debugging

Il concetto fa miracoli per metterti in una mentalità adeguata per lavorare attraverso il codice come se fosse nuovo.

Oltre agli strumenti utili menzionati in altre risposte, penso che modificare la tua mentalità sia utile quando fai una revisione del codice. È sciocco, ma mi dico: "Sto indossando il mio cappello di revisione del codice". Faccio lo stesso con il QA.

Quindi è importante limitarsi a quella mentalità. Sei il revisore o il revisore, non puoi essere entrambi contemporaneamente. Quindi, come revisore, prendo appunti oggettivi da condividere con il revisore. Non cambio il codice mentre lo sto rivedendo, non è qualcosa che un revisore dovrebbe fare.

La formalità a volte sembra un po 'assurda, ma quando lavoro da solo trovo che spesso mi muovo in molte direzioni. Quindi potrei non chiudere necessariamente il ciclo di revisione prima che emerga qualcos'altro - quella formalità (e davvero, sto parlando di note approssimative in uno strumento wiki), è utile per assicurarsi che la revisione venga eseguita. Allo stesso modo con il mio cappello QA attivo, aggiungo i biglietti per i bug prima di risolverli.

Sembra che il sentimento comune sia che l'auto-revisione non sia efficace. Non sono d'accordo, e penso che l'auto-revisione possa cogliere molti problemi se fatto a fondo.

Ecco alcuni suggerimenti della mia esperienza pluriennale:

• Tieni a portata di mano una lista di controllo approssimativa. Queste sono le cose che vuoi segnalare mentre leggi il tuo codice.
• Porta la recensione del codice offline. Potrebbe sembrare dispendioso, ma prendi le stampe che puoi annotare e capovolgere avanti e indietro, o l'equivalente digitale di PDF ben evidenziati sincronizzati su un iPad che viene quindi portato offline. Allontanati dalla scrivania, in modo che tutto ciò che fai sia rivedere il codice senza distrazioni.
• Fallo al mattino presto, piuttosto che alla fine di una giornata lavorativa. Un nuovo paio di occhi è meglio. In effetti, potrebbe essere utile essere stati lontani dal codice un giorno prima di rivederlo di nuovo.

Solo una FYI: queste linee guida facevano parte delle raccomandazioni di Oracle alcuni anni fa, quando stavo lavorando lì, dove l'obiettivo era quello di catturare i bug "a monte" prima che il codice andasse in prova. Ha aiutato molto, anche se è stato considerato un lavoro noioso da molti sviluppatori.

La tecnica del processo software personale per le recensioni potrebbe essere utile, sebbene si basi sul fatto di disporre di dati storici sul tuo lavoro e sulla qualità dei prodotti.

Inizi con i dati storici sui tuoi prodotti di lavoro, in particolare il numero e il tipo di difetti. Esistono vari metodi per classificare i difetti, come questo da un corso PSP . Puoi sviluppare il tuo, ma l'idea è che devi essere in grado di dire quali errori stai facendo lungo la strada.

Una volta che sai quali errori stai commettendo, puoi sviluppare una lista di controllo che puoi usare durante una revisione. Questa lista di controllo coprirebbe i principali errori che stai commettendo e pensi che tu possa essere meglio colto in una recensione (invece di usare qualche altro strumento). Ogni volta che si esamina un prodotto di lavoro, utilizzare l'elenco di controllo e cercare quegli errori o errori, documentarli e correggerli. Rivedi periodicamente questo elenco di controllo di volta in volta per assicurarti di concentrarti su problemi reali e pertinenti nel tuo codice.

Consiglierei anche di utilizzare il supporto degli strumenti quando ha senso. Gli strumenti di analisi statica possono aiutare a trovare alcuni difetti e alcuni addirittura supportano il controllo dello stile per imporre coerenza e buon stile di codice. L'uso di un IDE con il completamento del codice e l'evidenziazione della sintassi può anche aiutarti a prevenire o rilevare alcuni problemi prima di fare clic su "build". I test unitari possono coprire problemi logici. E se il tuo progetto è sufficientemente grande o complesso, l'integrazione continua può combinare tutti questi in un processo regolarmente eseguito e produrre report interessanti per te.

Lavorare da soli significa che, a meno che non ti fidi di estranei completi a rivedere il codice per tuo conto, dovrai osservare il modo in cui scrivi il tuo software per mantenere la qualità del codice.

Prima di tutto, dovresti avere un mezzo per assicurarti che il tuo codice soddisfi i requisiti, e in secondo luogo che il tuo codice sarà relativamente facile da cambiare se decidi in seguito che hai sbagliato qualcosa. Il mio suggerimento sarebbe quello di applicare un approccio di sviluppo guidato dal comportamento per i seguenti motivi:

1. BDD significa scrivere prima il test del codice. Ciò garantisce che tutto il codice sia coperto da test.
2. BDD è essenzialmente TDD, ma con un focus e un "linguaggio" leggermente diversi. Ciò implica che refactifichi continuamente il codice mentre lo stai lavorando e utilizzi i test per garantire che i tuoi sforzi di refactoring continuino a garantire che il codice soddisfi le specifiche del tuo prodotto.
3. Il linguaggio BDD incoraggia i test da scrivere sotto forma di dichiarazioni che essenzialmente codificano i requisiti come test unitari.

Quindi l'idea qui, è che il tuo continuo refactoring del codice anche dopo aver superato i test, significa che stai riesaminando efficacemente il tuo codice e usando i tuoi test unitari come "coppia extra di occhi" che assicurano che il tuo codice non lo faccia ' Deviare dai requisiti codificati nei test. Inoltre, un'elevata copertura dei test basata sui requisiti ti garantisce di poter modificare il codice in futuro senza soddisfare i requisiti.

Il vero problema per te sarà se sei in grado di individuare potenziali problemi nel tuo codice che indicheranno la necessità di refactoring. Esistono diversi strumenti di profilazione sul mercato che possono aiutarti in questo, così come molti altri strumenti che riguardano la metrica della qualità del codice. Questi possono spesso dirti molte cose che le recensioni di codice possono perdere e sono indispensabili quando si sviluppano progetti da soli. In realtà, tuttavia, l'esperienza è la chiave, e una volta che hai l'abitudine di essere spietato nel tuo refactoring, probabilmente diventerai molto più critico nei confronti del tuo codice. Se non lo hai già fatto, suggerirei di leggere il libro Refactoring di Martin Fowler come punto di partenza e di cercare una buona API BDD che ritieni possa funzionare per te in qualsiasi lingua tu abbia scelto di lavorare.

Ogni volta che mi sono trovato nella tua stessa situazione, ho cercato di risolvere il problema di "essere troppo vicino al codice per esaminarlo obiettivamente" utilizzando gli strumenti di revisione / metrica del codice. Va da sé che uno strumento non può dare lo stesso valore di un revisore esperto, ma è comunque possibile utilizzarli per individuare aree di cattiva progettazione.

Uno strumento che ho trovato abbastanza utile in questo senso è stato SourceMonitor . È un po 'semplicistico, ma offre una buona opinione di medio livello del codice, come il numero di metodi in una classe e la complessità di ciascun metodo. Ho sempre pensato che questo tipo di informazioni fosse altrettanto importante (se non più importante di) l'applicazione degli stili di codifica tramite strumenti come StyleCop, ecc. (Che sono importanti, ma spesso non sono la fonte dei maggiori problemi). Usa questi strumenti con le solite dichiarazioni di non responsabilità: sapere quando infrangere una regola empirica e qualcosa che è tutto verde in uno strumento di metrica del codice non è automaticamente di buona qualità.

Non posso dirti quante volte ho spiegato qualcosa a un revisore del codice e la lampadina nella mia testa si accende e dice "Ehi aspetta un minuto". Quindi trovo spesso i miei errori nella revisione del codice che l'altra persona non ha visto. Quindi puoi provarlo, basta iniziare a spiegare il codice come se ci fosse una persona seduta accanto a te che stava cercando di capire cosa hai fatto e perché.

Un'altra cosa che trovo spesso nelle revisioni del codice è che lo sviluppatore non ha effettivamente seguito il requisito. Quindi confrontare il tuo codice e quello che fa il requisito effettivo è un buon controllo.

Facciamo spesso cose come pacchetti SSIS che hanno esigenze strutturali simili: per le revisioni del codice ho sviluppato un elenco di controllo di cose da controllare (la configurazione è corretta, la registrazione è impostata, utilizza il database dei metadati, sono i file nella posizione standard, eccetera.). Potresti avere alcune cose che sarebbe utile controllare ogni volta anche in una revisione del codice. Siediti e pensa a cosa inseriresti in un elenco di controllo delle cose che desideri verificare nella revisione del codice (Primo elemento, assicurati che il requisito sia soddisfatto, l'elemento successivo potrebbe avere a che fare con errori di trapping e registrazione). Man mano che si commettono errori e li si corregge, è possibile aggiungere altri elementi all'elenco (dire qualcosa del genere, devo passare al record successivo in un ciclo o sto per ripetere all'infinito lo stesso primo elemento - ci vuole solo un ciclo infinito per ti insegnano a cercarlo!).

Dagli 3 mesi, poi torna indietro e guarda il tuo codice. Te lo prometto, se non riesci a trovare qualcosa di sbagliato (o domanda su chi ha scritto questa spazzatura!) Sei un uomo migliore di me!

Di solito stampo tutto il mio codice e mi siedo in un ambiente tranquillo e lo leggo, trovo molti errori di battitura, problemi, cose da refactoring, ripulendo facendo quello. È un buon autocontrollo che penso che tutti dovrebbero fare.

Al college ero un tutor di scrittura. Mi ha sicuramente dato alcune prospettive sulla programmazione che penso che molti sviluppatori non avrebbero mai pensato. Uno dei più importanti è leggere ad alta voce il tuo codice. Non suona molto, ma darò un esempio perfetto a cui penso che tutti possano relazionarsi.

Hai mai scritto un'e-mail o un documento, riletto più volte per assicurarti che sia corretto, quindi lo hai inviato, solo per scoprire che hai un errore di ortografia, errore di battitura o grammaticale evidente? L'ho fatto ieri quando ho chiesto a un cliente di premere il tasto Merda invece del tasto Maiusc. Quando leggi nella tua testa, vedi quello che vuoi vedere.

Questa è una scorciatoia per i suggerimenti "aspetta un giorno o una settimana o un mese" che altri hanno avanzato. Se lo leggi ad alta voce, catturi le stesse cose. Non so perché sia ​​così efficace, ma dopo essermi seduto con centinaia di studenti e averli letti ad alta voce, tutto quello che posso dire è che funziona.

La maggior parte delle persone tende a considerare il proprio codice come i propri figli e alimentarli con ego piuttosto che con la realtà. Proprio come qualsiasi altra recensione di codice, esaminala mentre vedi il codice di qualcun altro. Dimentica completamente che hai scritto qualcosa. Rivedi ogni riga del codice. Un elenco di controllo sarebbe utile per essere estetico sulla revisione del proprio codice. Gli strumenti automatizzati per la revisione del codice possono aiutare in qualche misura. Ho usato alcuni strumenti come klocwork (software commerciale), questo è abbastanza utile mentre lavori in progetti di grandi dimensioni e molti sviluppatori ci lavorano. Concentrarsi sempre sul rilevamento dei difetti piuttosto che sulla correzione.

Ma una buona pratica sarebbe, rivedere te stesso e in seguito coinvolgere almeno altre due persone per la revisione con ruoli distinti.

Considera di fare un'ispezione Fagan da solo: dovrai adattare il processo perché sei da solo, ma dovresti essere in grado di ricavarne un bel po 'di valore. Il trucco sarà quello di trovare il giusto "set di regole" per valutare il tuo codice come uno sviluppatore solista, e quindi avere la disciplina di porre tali domande in uno stato d'animo critico, analitico, spietato ogni volta. Ho il sospetto che potresti voler brainstorming delle tue 4-5 domande cruciali per cominciare, e poi evolverlo nel tempo. Alcune persone sono contrarie alle ispezioni formali perché sembrano essere molto dispendiose in termini di tempo ... prima che tu decida che sono troppo costose, tieni a mente tutte le prove statistiche che fare ispezioni in modo corretto riduce effettivamente i tempi di progetto. Ecco un link Wikipedia con cui puoi iniziare ulteriori ricerche con:

http://en.wikipedia.org/wiki/Software_inspection

Ci sono stati anche alcuni libri, ad esempio Google per "Processo di ispezione del software" di Strauss ed Ebenau.

Un'altra opzione è quella di pagare qualcuno per ispezionare un progetto importante - o forse pagare di tanto in tanto per fare ispezioni di tutto il codice. Questo ragazzo è abbastanza bravo, lo abbiamo fatto volare diverse volte per addestrare i nostri nuovi sviluppatori:

http://www.javaspecialists.eu/

Oltre a tutti i consigli per la revisione del codice, puoi usare strumenti come PMD e findBug per fare il primo livello di sanità mentale per il tuo codice.

Questo non è stato ancora inserito in una risposta (ma è stato aggiunto come commento a una risposta esistente)

Rivedi il tuo codice dopo una buona notte di sonno, ad esempio inizia la giornata rivedendo il codice che hai scritto il giorno precedente.

Questo ovviamente non ti darà l'esperienza collettiva di una squadra, ma ti permetterà di rivedere il codice da una nuova prospettiva.

Ad esempio, se hai lasciato un pezzo di codice con un brutto hack, potresti non essere troppo incline a sistemarlo, se rivedi il tuo codice immediatamente dopo. Dopotutto, quando inizi a rivedere il tuo codice, sai già e hai accettato la presenza di questo hack. Ma se hai dormito bene, probabilmente sei più motivato a trovare una soluzione migliore.

Quando dormiamo, il cervello in realtà non smette di lavorare sui problemi che abbiamo, quindi potresti effettivamente trovare una soluzione lì, anche se a volte queste soluzioni possono presentarsi in modi strani .