Mi è stato assegnato il ruolo di migliorare lo sviluppo nella nostra azienda. La prima cosa che volevo iniziare erano le revisioni del codice poiché non è mai stato fatto qui prima.

Ci sono 3 programmatori nella nostra azienda. Sono un programmatore web, le mie lingue conosciute sono principalmente PHP, ActionScript e JavaScript. Gli altri 2 sviluppatori scrivono applicazioni interne in VB.net

Facciamo revisioni del codice da un paio di settimane ormai. Trovo difficile capire il codice VB. Quindi quando dicono che cosa sta facendo, per la maggior parte devo solo prendere la parola per questo.

Se vedo qualcosa che sembra sbagliato, spiego la mia opinione e spiego come lo affronterei in una delle lingue che conosco.

A volte i miei suggerimenti vengono accolti, ma molte volte mi viene detto cose come "questo è il modo migliore di farlo in questa lingua" o "che non si applica a questa lingua" o cose simili di quella natura.

Questo può essere vero, ma senza conoscere la lingua non sono sicuro di come confermare o confutare queste affermazioni.

So che una possibile soluzione sarebbe quella di imparare VB in modo da poter fare migliori recensioni di codice. Non ho alcun interesse per l'apprendimento del VB (soprattutto perché ho un elenco di altre tecnologie che sto cercando di imparare per i miei progetti) e vorrei mantenerlo come ultima risorsa, ma è un'opzione.

Un'altra idea che mi è venuta in mente è che entrambi hanno interesse per C # e anche io. È relativo a loro perché è .net e relativo a me perché è più simile alle lingue che conosco. Eppure è nuovo per tutti noi. Ho pensato ai vantaggi di tutti noi che collaboriamo a un progetto C # .net per animali domestici e che ne esaminiamo il codice a vicenda.

Immagino ci sia anche la possibilità di assumere un consulente per entrare e darci alcune revisioni del codice.

Cosa mi consiglieresti di fare in questa situazione.

I tuoi desideri personali di apprendere altre cose dovrebbero fare un passo indietro nell'apprendere ciò di cui hai effettivamente bisogno in questo momento per il tuo lavoro. Scopri VB.net. Puoi effettivamente codice di revisione del codice che non capisci quando conosci la lingua in cui ti trovi ponendo molte domande (di solito è un segno che il codice non è ben scritto se conosci la lingua e non riesci a capire cosa sta facendo e perché). Ma non capendo il codice, il meglio che puoi fare è convincerli a spiegartelo e sperare che vedano eventuali bug durante il processo di spiegazione. Non che non ho trovato bug nel mio codice in una recensione facendo proprio questo, ma non è il modo più efficace per la revisione del codice. La revisione del codice fa ora parte del tuo lavoro, affrontalo e impara cosa devi imparare per farlo in modo efficace.

Mentre stai imparando, quando dicono bene che non è il modo in cui lo facciamo in questa lingua, fai che ti mostrino una fonte che dice che è una buona tecnica da usare. Sta a loro giustificarti in una revisione del codice e non viceversa. Migliorerai anche la lingua una volta che inizi a vedere quei link.

In realtà, non sono d'accordo con tutto quanto sopra. Con JS / PHP / ActiopnScript, hai una conoscenza fondamentale di ciò che ha un linguaggio di programmazione e di come funziona. In effetti, direi che ci sono molte somiglianze tra VB e JS. Tuttavia, non è questo il punto. Anche se sei molto competente con la lingua, è facile trascurare qualcosa quando si tenta di seguire i processi di pensiero di qualcun altro, quindi ciò che la recensione dovrebbe fare è offrire al programmatore l'opportunità di spiegare cosa ha fatto e perché.

Una volta un amico lo ha descritto come "The Janitor Theory": spiegando i dettagli a qualcuno, a chiunque, persino al bidello, il programmatore espone a se stesso eventuali punti deboli del codice, che è, ovviamente, l'obiettivo finale della recensione processi. Richiede, tuttavia, che il codice sia spiegato in modo completo e aperto (le recensioni non funzionano quando gli sviluppatori sono difensivi).

La versione corta

1. Ricorda che le revisioni del codice sono una possibilità sia per il revisore che per il revisore di apprendere.
2. Frase di feedback come una domanda.
3. Non lasciare che la mancanza di conoscenza ti impedisca di fornire feedback (fintanto che stai facendo # 2).
4. Evita le "recensioni di preferenze" o almeno cerca di chiarire che sono le tue preferenze personali e che non devono necessariamente essere d'accordo.
5. Prova a inviare le patch invece di essere un "revisore del codice poltrona".

La versione più lunga

Prima di tutto, ricorda che la revisione del codice non è solo un'opportunità per il revisore di imparare. È anche un'opportunità per il revisore di imparare. In effetti, ho sentito parlare di diverse organizzazioni che fanno iniziare i nuovi programmatori a fare revisioni del codice in modo che possano avere un'idea del codice.

Con questo in mente, c'è un consiglio di revisione del codice che ho sempre trovato utile in generale, ma è particolarmente pertinente nella tua posizione. Frase il tuo feedback sotto forma di una domanda piuttosto che come una dichiarazione. In altre parole, invece di dire "Questo codice fa schifo!", Potresti dire "Perché hai scritto il codice in questo modo invece di fare ..." Questo rende il processo di revisione del codice più piacevole e ti permette anche di imparare.

Un altro consiglio che ho per te è di non lasciarti andare alla tua mancanza di conoscenza. Se vedi qualcosa che percepisci come sbagliato e ricevi una risposta ondulata dal recensore, non fare un passo indietro (almeno non a causa della mancanza di conoscenza). Ricorda, ciò che rende un buon codice in una lingua è raramente diverso da ciò che rende un buon codice in qualsiasi altra lingua. Sì, alcune lingue hanno idiomi diversi per aiutarti a scrivere un buon codice. Ma è importante rendersi conto che quegli idiomi sono strumenti piuttosto che fini a se stessi.

Quindi, cerca di evitare di fare "recensioni di preferenze". Questo è qualcosa che io (e molti altri) devo fare uno sforzo molto consapevole. In altre parole, cerca di evitare di fare recensioni simili a "Hai fatto x , ma preferisco y ". Ora, non c'è niente di sbagliato nell'affermare le preferenze, ma dovresti chiaramente etichettarle come tali e prendere nota che l'altra parte è libera di essere in disaccordo. Questo è importante, perché la maggior parte delle cose che differiscono da una lingua all'altra rientrano in questa categoria.

Infine, ragazzi usate un sistema di controllo della versione distribuita? Una cosa che potrebbe aiutare è se invece di notare semplicemente cosa non va nel codice, potresti riscrivere il codice come lo avresti scritto, testarlo e quindi inviarne una patch. Questo aiuta a dimostrare che sei veramente interessato a migliorare il loro codice e non solo a essere un "revisore del codice poltrona" e ti dà la possibilità di imparare meglio la lingua. Inoltre, di solito è più facile non essere d'accordo con "Penso che dovresti farlo" di quanto non lo sia "Ecco come avrei fatto, ed ecco una patch se sei d'accordo". Suppongo che non sia necessario necessariamente un DVCS per questo, ma sicuramente aiuta.

Hai perso la concentrazione sul problema e hai trovato una soluzione scadente. Ti è stato assegnato il compito di migliorare lo sviluppo e la tua soluzione è quella di incaricare un responsabile della revisione del codice (te stesso) che non capisce la lingua. Chi sta rivedendo il tuo codice? Perché non riescono a rivedersi l'un l'altro fino a quando non impari la lingua?

Ci deve essere un'altra area problematica che avrebbe potuto scegliere di avere un miglioramento più immediato. In questo modo ti soffiano solo fumo e niente migliora.

Dirigere il nuovo sviluppo verso un linguaggio che nessuno di voi capisce (C #) impiegherà molto tempo per ripagare, specialmente se tutti portate con sé le loro cattive abitudini.

Focus sul design (è stato menzionato.). Se hanno difficoltà a mantenere il codice corrente, cerca alcuni strumenti di refactoring per VB. Molte delle pratiche di base sono le stesse.

Puoi "provare a leggere" cose che non conosci veramente, ma non puoi esaminarle adeguatamente . Sono altamente competente in C, conosco C ++ piuttosto bene, ma non mi sognerei di rivedere qualcosa in C #.

Non penso che tu debba andare fino a coinvolgere un consulente, poiché alcune aziende sono specializzate nell'esecuzione del tuo codice attraverso una tonnellata di test e ti dicono cosa potrebbe esserci di sbagliato in esso.

Tuttavia, spetta al singolo sviluppatore che conosce la lingua per interpretare il risultato. Ad esempio, se un revisore del codice mi ha rifiutato di non utilizzare il valore restituito di printf(), li guarderei in modo strano e metterei in discussione la loro sobrietà, quindi chiedere "Ok, fantastico, cosa posso fare quando non è possibile stampare sulla console nulla che possa Sii utile?"

Ciò che potresti voler considerare è parlare con i tuoi capi della creazione di dipartimenti e lead di team, in modo che tu possa essere efficace nel tuo dominio, mentre qualcun altro è efficace nel loro dominio.

Tuttavia, penso che potresti essere in grado di utilizzare una terza parte per l'auditing. La maggior parte dei programmatori che meritano il loro sale presterà attenzione alle preoccupazioni legittime , anche se ne considerano metà falsa (come farei nel mio printf()esempio).

Fornire una guida su qualcosa che non capisci è simile al cieco che guida il cieco poiché tu sei ben consapevole.

Un approccio sarebbe quello di utilizzare strumenti di sfilacciatura come FxCop e StyleCop che affronteranno il fronte dell'analisi statica della base di codice. Ciò fornirebbe un punto di partenza per discutere i report generati dagli strumenti.

Un altro approccio sarebbe quello di trasformare le revisioni del codice in revisioni del progetto. Le revisioni del progetto più spesso non rivelano problemi molto prima ancora che il codice venga scritto. Se un programmatore ha una progettazione da cui può lavorare, in generale è molto più efficiente nel suo approccio e gli errori diminuiscono a causa di ciò. Quando un progetto è inesistente, diventa ad hoc nell'approccio e il codice soffre con l'aumentare del conteggio dei bug. Cattura i problemi nella revisione del progetto prima che emergano nella revisione del codice assicurandoti che ognuno di voi abbia un progetto concreto da implementare; UML è il tuo amico qui e strumenti come umlet sono veloci e veloci da usare.

La cattiva notizia è che per partecipare efficacemente alle revisioni del codice, dovrai imparare VB. Sarà anche utile usare VB in una sorta di progetto (non necessariamente per la produzione).

La buona notizia è che una volta che hai fatto questo, alcune delle cose che hai imparato saranno ancora utili quando passerai a C #.

Il pensiero che dovresti tenere sempre quando fai la peer review è:

"SONO IL PROSSIMO A MANTENERE QUESTO CODICE!"

Devi comprenderlo abbastanza bene da poterlo fare come parte della tua preparazione alla revisione, e il tuo compito è quello di rendere il programmatore originale consapevole di eventuali carenze che lo hanno reso più ingombrante del necessario per capire il codice abbastanza bene da mantenerlo .

Se non è possibile programmare in VB, non è possibile mantenere il codice e non si è qualificati per essere peer reviewer.

Non dovresti rivedere il codice che non capisci, questo infastidirà solo gli sviluppatori che devono spiegare ogni cosa strana che hanno fatto.

Cosa puoi fare scegli / definisci le linee guida per la codifica e controlla il codice rispetto a queste linee guida. Quando qualcosa non è conforme alle linee guida è possibile chiedere spiegazioni allo sviluppatore.

Vorrei iniziare con la scelta delle linee guida esistenti (non conosco alcun standard di codifica VB.net ma google mi ha dato:

• Linee guida per la codifica VB .Net
• Submain
• Tutto in un unico framework di codice

Usa strumenti simili a stylecop per VB .net

Analizza le fonti con NDepend (ha regole sulla complessità, lunghezza, profondità ecc. Ciclomatiche )

Quando hai fatto ciò, puoi dire che il codice è conforme agli standard scelti, non dice nulla sulla funzionalità corretta o sul codice che utilizza i principi OOP appropriati. Ma almeno è qualcosa.

Una buona recensione del codice riguarda le cose che richiedono di comprendere la lingua - uso appropriato della lingua, API e librerie, stile, nomi delle variabili ecc. - e di come il codice risolve il problema - buoni commenti, architettura adeguata, design pertinente schemi, considera tutti i casi di errore, ecc. Quando inizi a fare revisioni del codice tendi a concentrarti sul primo. Sono più facili da vedere e più facili da imparare. (ad es. non mi piacciono i nomi delle tue variabili. Dovresti usare i nomi in stile XXXX.)

La revisione del codice diventa più preziosa quando si concentra maggiormente la capacità del codice di risolvere i problemi. Dal momento che non puoi fornire lo stesso valore nella prima area ora, concentrati sul porre domande e offrire consigli sulla soluzione del problema, non su come è fatto.

Naturalmente c'è una sovrapposizione tra i due. Conoscere VB.NET ti consentirebbe di fornire consigli sul perché un determinato modello di progettazione non è una buona scelta in una situazione particolare, ad esempio.

Soprattutto, sii umile in questa fase. Cambiare processo è difficile. Anche se fossi un guru di VB.NET, il cambiamento probabilmente non sarebbe facile. Alle persone che non hanno usato la revisione del codice all'inizio non piace. Avere gli altri a guardare il tuo codice è un'esperienza difficile. Ci vuole tempo per vedere il valore e la pazienza intorno. È un ottimo processo quando ricevi il buy-in ma ci vorrà del tempo.

Potresti spostare l'attenzione per essere più sui test piuttosto che guardare direttamente il codice? Non sto dicendo di abbandonare le recensioni del codice, ma inizialmente potrebbe essere più sensato fare in modo che quelle app interne abbiano test sufficienti che possano aiutare a decodificare alcuni di ciò che sta accadendo. L'idea qui è che i test potrebbero anche aiutarti a familiarizzare con alcune funzionalità. Vedo solo questo come un percorso diverso da prendere. L'idea qui è che le recensioni tornino più tardi e possono essere fatte in un paio di parti in quanto potrebbe essere utile avere una panoramica / sessione iniziale e poi un po 'di pausa. L'interruzione è fino al giorno successivo o due in modo che ci sia abbastanza tempo per chiunque possa desiderare di dormire una notte pensando al codice o qualcosa di simile prima di tornare con domande e discutere.

Naturalmente se hai già dei test, purtroppo non è poi così significativo. L'altro pensiero è quello di fornire un esempio di dove sostengono che in VB.Net ciò è fatto in un modo particolare, in quanto ciò potrebbe aiutare a rendere questa domanda più chiara in un modo come potrei immaginare che varia da piccoli standard di codice a parte di il cuore di come VB.Net è stato costruito in un certo senso.

Anche se apprendi le basi di VB, eseguire una revisione del codice pur non conoscendo tutte le funzionalità della lingua non ti consentirà di rilevare l'utilizzo di funzionalità non sicure nella lingua.

Supponiamo di non essere a conoscenza del fatto che la funzione input () in Python 2 abbia effettivamente valutato l'input prima di restituirlo, al fine di semplificare l'analisi dei tipi di input non stringa. Quindi il codice sarebbe vulnerabile all'esecuzione arbitraria del codice, consentendo all'utente di inserire qualcosa come __import__('os').execl('/bin/sh', '/bin/sh')un sistema Linux per trasformare il processo Python in una shell. Invece, raw_input () dovrebbe essere usato per ottenere i dati di input non elaborati.

Tentare di eseguire una revisione del codice pur non conoscendo tutte le funzionalità della lingua potrebbe non solo impedirti di realizzare un modo migliore per eseguire una determinata procedura nella lingua; potrebbe anche portare a difetti di sicurezza dannosi.