Sto lavorando a un progetto da solo e devo mantenere il mio codice. Solitamente la revisione del codice non viene eseguita dall'autore del codice, quindi il revisore può guardare il codice con gli occhi nuovi - tuttavia, non ho un tale lusso. Quali pratiche posso impiegare per rivedere più efficacemente il mio codice?
Prima di tutto, usa gli strumenti per controllare il più possibile. I test (supportati da una ragionevole copertura del codice) ti daranno un po 'di fiducia sulla correttezza del codice. Gli strumenti di analisi statica possono catturare molte delle best practice. Ci saranno sempre problemi per i quali hai bisogno di occhi umani per determinarli e non farai mai un buon lavoro rivedere le tue cose come qualcun altro, ci sono alcune cose che puoi fare per aiutarti comunque
Questo è ovviamente utile anche quando stai rivedendo il codice degli altri
Dai un'occhiata al esame del codice sito di scambio di stack. È per condividere il codice dai progetti su cui stai lavorando per revisione tra pari :
Code Review Stack Exchange is a question and answer site for seeking peer review of your code. We're working together to improve the skills of programmers worldwide by taking working code and making it better.
If you are looking for feedback on a specific working piece of code from your project in the following areas…
- Best practices and design pattern usage
- Security issues
- Performance
- Correctness in unanticipated cases
Puoi anche utilizzare gli strumenti di analisi statica del codice per rilevare determinati tipi di problemi, ma in alcuni casi produrranno falsi allarmi e non è in grado di suggerire come migliorare la progettazione.
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 degli altri.
Raccomando caldamente il mio approccio.
ps Non sta scherzando.
Sono d'accordo con l'opinione di jk-s che la revisione di una sola persona non è efficiente come quella di 2 persone. tuttavia puoi provare a sfruttarlo al meglio:
recensione a breve termine (poco dopo che il codice è stato prodotto)
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 cambiato nel mio codice e ripenso:
recensione a lungo termine (6 mesi dopo la produzione del codice)
Mi chiedo:
Per prima cosa, imposta il codice a parte finché è più pratico. Lavora su qualcos'altro, qualche altro pezzo di codice. Anche dopo un giorno, sarai sbalordito da ciò che troverai.
In secondo luogo, documenta il tuo codice. Molti programmatori odiano documentare il proprio codice, ma sii costretto a sedersi e scrivere la documentazione, come usare il codice e come funziona. Osservando il tuo codice in un modo diverso, troverai degli errori.
È stato detto che la vera padronanza di un soggetto è la capacità di insegnarlo a qualcun altro. Con la documentazione stai cercando di insegnare a qualcun altro il tuo codice.
Oltre agli strumenti utili menzionati in altre risposte, ritengo che modificare la tua mentalità sia utile quando si esegue una revisione del codice. È sciocco, ma mi dico: "Sto indossando il mio cappello per la revisione del codice". Faccio lo stesso con il QA.
Quindi è importante limit te stesso per quella mentalità. Sei il revisore o il recensore, non puoi essere entrambi contemporaneamente. Quindi, come recensore, prendo note oggettive da condividere con il recensore. 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 sono spesso coinvolto in molte direzioni. Quindi potrei non chiudere necessariamente il ciclo di revisione prima che venga fuori qualcos'altro: quella formalità (e in realtà, sto parlando di note approssimative in uno strumento wiki), è utile per assicurarci che la revisione sia fatta. Allo stesso modo con il mio QA hat on, aggiungo ticket per i bug prima di correggerli.
Sembra che il sentimento comune sia che l'auto-revisione non è efficace. Non sono d'accordo, e penso che l'auto-revisione può prendere un sacco di problemi se fatto a fondo.
Ecco alcuni suggerimenti dei miei pochi anni di esperienza:
Solo una FYI - queste linee guida facevano parte delle raccomandazioni di Oracle alcuni anni fa quando lavoravo lì, dove lo scopo era catturare i bug "a monte" prima che il codice andasse in testing. Ha aiutato molto, anche se è stato considerato un lavoro noioso da molti sviluppatori.
La tecnica del processo di personal software per le recensioni potrebbe essere utile, anche se si basa sull'avere dati storici sul tuo lavoro e sulla qualità dei prodotti.
Inizi con i dati storici relativi ai tuoi prodotti di lavoro, in particolare il numero e i tipi di difetti. Esistono vari metodi per classificare i difetti, come questo uno da un corso PSP . Puoi sviluppare il tuo, ma l'idea è che devi essere in grado di dire quali errori stai facendo lungo il percorso.
Una volta che sai quali errori stai facendo, puoi sviluppare una lista di controllo che puoi usare durante una revisione. Questa lista di controllo coprirà gli errori principali che stai facendo che pensi possano essere meglio catturati in una recensione (invece di usare qualche altro strumento). Ogni volta che rivedi un prodotto di lavoro, usa la lista di controllo e cerca quegli errori o errori, documentali e correggili. Periodicamente rivedi questo elenco di controllo di volta in volta per assicurarti di concentrarti su problemi reali e rilevanti nel tuo codice.
Raccomando anche di usare il supporto degli strumenti quando ha senso. Gli strumenti di analisi statica possono aiutare a trovare alcuni difetti e alcuni addirittura supportano il controllo degli stili per rafforzare la coerenza e lo stile del codice. L'utilizzo di un IDE con il completamento del codice e l'evidenziazione della sintassi può anche aiutare 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 aspetti in un processo a esecuzione regolare e produrre buoni rapporti per te.
Lavorare da solo significa che, a meno che non ti fidi di estranei completi per rivedere il codice per tuo conto, dovrai controllare 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 di avere qualcosa di sbagliato. Il mio suggerimento sarebbe di applicare un approccio Sviluppo guidato dal comportamento per i seguenti motivi:
Quindi l'idea qui è che il tuo continuo refactoring del codice anche dopo aver superato i test, significa che stai effettivamente rivedendo il tuo codice e usando i tuoi test unitari come "extra pair of eyes" che assicurano la tua il codice non si discosta dai requisiti che sono codificati nei test. Inoltre, un'elevata copertura di test basata sui requisiti garantisce che sarai in grado di cambiare il tuo codice in futuro senza averne i requisiti.
Il vero problema per te sarà se sarai in grado di individuare potenziali problemi nel tuo codice che indicheranno la necessità di un refactoring. Esistono diversi strumenti di profilatura sul mercato che possono aiutarti con questo, così come molti altri strumenti che riguardano le metriche sulla qualità del codice. Questi possono spesso dirti molte cose che le recensioni del codice possono mancare e sono indispensabili per lo sviluppo di progetti per conto tuo. 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 del tuo codice. Se non lo hai già fatto, ti suggerisco di leggere il libro Refactoring di Martin Fowler come punto di partenza, e alla ricerca di una buona API BDD che ritieni possa funzionare per te nella lingua che hai scelto di utilizzare.
Ogni volta che sono stato nella stessa situazione, ho cercato di risolvere il problema di "essere troppo vicino al codice per esaminarlo oggettivamente" usando gli strumenti di revisione / metrica del codice. Inutile dire 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 a questo proposito è stato SourceMonitor . È un po 'semplicistico, ma offre una buona opinione di medio livello sul codice, come il numero di metodi in una classe e la complessità di ciascun metodo. Ho sempre pensato che questo tipo di informazione fosse importante (se non più importante) dell'applicazione degli stili di codifica tramite strumenti come StyleCop, ecc. (Che sono importanti, ma spesso non sono la fonte dei maggiori problemi). Utilizza 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 potresti provare, 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 ciò che fa il requisito reale è un buon controllo.
Spesso facciamo cose come i pacchetti SSIS che hanno esigenze strutturali simili - per le revisioni del codice ho sviluppato una lista di cose da verificare (la configurazione è corretta, la registrazione è configurata, usa il database dei metadati, sono i file nella posizione standard, ecc.). Potresti avere alcune cose che sarebbe utile controllare ogni volta in una revisione del codice. Siediti e pensa a cosa inseriresti in una lista di cose che vuoi assicurarti di controllare nella revisione del tuo codice (prima cosa, assicurati che il requisito sia soddisfatto, l'elemento successivo potrebbe avere qualcosa a che fare con errori di trapping e di registrazione). Se commetti errori e li correggi, puoi aggiungere altri elementi alla lista (dì qualcosa di simile, passo al ciclo successivo in un ciclo o sto andando a ripetere all'infinito lo stesso primo oggetto - ci vuole solo un ciclo infinito per ti insegnano a cercarlo!). Questo è principalmente per impedirti di dimenticare di fare alcune cose che dovrebbero essere fatte.
Dagli 3 mesi, poi torna indietro e guarda il tuo codice. Te lo prometto, se non riesci a trovare qualcosa di sbagliato (o domanda a 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 un sacco di errori di battitura, problemi, cose da refactoring, pulizia facendo così. È un buon autocontrollo che penso che tutti dovrebbero fare.
Al college ero un insegnante 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 sembra molto, ma darò un esempio perfetto a cui penso che tutti possano identificarsi.
Hai mai scritto un'email o un documento, riletto più volte per assicurarti che sia corretto, quindi inviato, solo per scoprire che hai un errore di battitura lampante, errore di battitura o errore grammaticale? 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 ciò che vuoi vedere.
Questa è una scorciatoia per i suggerimenti "aspetta un giorno o una settimana o un mese" che altri hanno fatto. Se lo leggi ad alta voce, prendi le stesse cose. Non so perché sia così efficace, ma dopo aver 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 un proprio bambino e ad alimentarlo con l'ego piuttosto che con la realtà. Proprio come qualsiasi altra recensione del codice, esaminala mentre vedi il codice di qualcun altro. Dimentica completamente di aver scritto qualcosa. Rivedi ogni riga del codice. Una lista di controllo sarebbe utile per essere estetici sulla revisione del proprio codice. Strumenti automatizzati per la revisione del codice possono aiutare in parte. Ho usato alcuni strumenti come klocwork (software commerciale), questo è molto utile mentre lavori su grandi progetti e molti sviluppatori stanno lavorando per questo. Concentrati sempre sul rilevamento dei difetti piuttosto che sulla correzione.
Ma una buona pratica sarebbe, rivedere te stesso e poi 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 sta nel trovare il giusto "set di regole" per valutare il tuo codice come uno strumento di sviluppo solitario, e poi avere la disciplina per porre queste domande in uno stato d'animo critico, analitico e spietato ogni volta. Ho il sospetto che potresti voler confrontare le tue 4-5 domande cruciali per iniziare, e poi evolverle nel tempo. Alcune persone sono contrarie alle ispezioni formali perché sembrano essere così ad alto dispendio di tempo ... prima di decidere che sono troppo costosi, tenete a mente tutte le prove statistiche che facendo correttamente le ispezioni riducono effettivamente i tempi del progetto. Ecco un link di Wikipedia che puoi avviare ulteriori ricerche con:
Ci sono stati anche alcuni libri, ad es. Google per "Software Inspection Process" di Strauss e Ebenau.
Un'altra opzione è pagare qualcuno per ispezionare un progetto importante - o forse pagarlo di tanto in tanto per fare ispezioni su tutto il tuo codice. Questo ragazzo è piuttosto bravo, l'abbiamo volato fuori più volte per addestrare i nostri sviluppatori più recenti:
Oltre a tutti i consigli per la revisione del codice, puoi utilizzare gli strumenti come PMD e findBug per fare il primo livello di sanità per il tuo codice.
Questo non è stato ancora inserito in una risposta (ma è stato aggiunto come commento ad una risposta esistente)
Verifica il tuo codice dopo una buona notte di sonno, ad es. inizia la giornata esaminando il codice che hai scritto il giorno precedente.
Ovviamente questo non ti darà l'esperienza collettiva di una squadra, ma ti darà la possibilità di rivedere il codice da una nuova prospettiva.
Ad esempio, se hai lasciato un pezzo di codice con un brutto attacco, potresti non essere troppo incline a risolverlo, se rivedi il tuo codice subito 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 trovare una soluzione lì, anche se quelle soluzioni a volte può presentarsi in modi strani .
Leggi altre domande sui tag solo-development code-reviews