I tuoi desideri personali di imparare altre cose dovrebbero passare in secondo piano per imparare ciò che effettivamente ti serve in questo momento per il tuo lavoro. Impara VB.net. Puoi efficacemente codificare il codice di revisione che non capisci quando conosci la lingua in cui si trova facendo 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 spero che vedranno eventuali bug attraverso il processo di spiegazione. Non che non abbia 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 ora fa parte del tuo lavoro, la gestisci e impara ciò che devi imparare per farlo in modo efficace.

Mentre stai imparando, quando dicono bene che non è il modo in cui lo facciamo in questa lingua, fagli mostrare una fonte che dice che è una buona tecnica da usare. Spetta a loro giustificarti in una revisione del codice, non viceversa. Potrai anche migliorare la lingua quando inizi a vedere quei link.

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

Un amico una volta descriveva questo come "The Janitor Theory": spiegando i dettagli a qualcuno, a chiunque, persino al custode, il programmatore espone a se stesso eventuali punti deboli del codice, che è, naturalmente, l'obiettivo finale del processo di revisione. Richiede, tuttavia, che il codice sia spiegato a fondo e apertamente (le recensioni non funzionano quando gli sviluppatori sono difensivi).

Hai perso attenzione al problema e hai trovato una soluzione scadente. ti è stato assegnato il compito di migliorare lo sviluppo e la tua soluzione è quella di affidare a un responsabile la revisione del codice ( te stesso) che non capisce la lingua. Chi sta revisionando il tuo codice? Perché non possono controllarsi a vicenda fino a quando non si impara la lingua?

Ci deve essere qualche altra area problematica da poter scegliere per avere un miglioramento più immediato. In questo modo soffiano solo fumo e niente migliora.

Dirigere nuovi sviluppi in un linguaggio che nessuno di voi capisce (C #) impiegherà molto tempo a pagare, soprattutto se tutti portano con sé le loro cattive abitudini.

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

La versione breve

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

La versione più lunga

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

Con questo in mente, c'è una parte di consigli sulla 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 più gradevole il processo di revisione del codice e ti consente anche di imparare.

Un altro consiglio che ho per te è di non lasciare che la tua mancanza di conoscenza ti faccia cadere. Se vedi qualcosa che percepisci come errato, e ottieni una risposta ondulata dal recensore, non tirarti indietro (almeno non per mancanza di conoscenza). Ricorda, ciò che rende il buon codice in una lingua è raramente diverso da ciò che rende il 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.

Inoltre, cerca di evitare di fare "recensioni di preferenza". Questo è qualcosa a cui io (e molti altri) devo fare uno sforzo molto consapevole. In altre parole, cerca di evitare di fare recensioni che sono sulla falsariga di "Hai fatto x , ma preferisco y ". Ora, non c'è niente di sbagliato nell'indicare le preferenze, ma dovresti etichettarle chiaramente come tali e prendere nota che l'altra parte è libera di non essere d'accordo. Questo è importante, perché molte cose diverse dalla lingua alla lingua rientrano in questa categoria.

Infine, voi ragazzi usate un sistema di controllo della versione distribuito? Una cosa che potrebbe essere d'aiuto è se invece di limitarti a notare cosa c'è di sbagliato nel codice, potresti riscrivere il codice come lo avresti scritto, testarlo e quindi inviare una patch per esso. Questo aiuta a dimostrare che sei veramente interessato a migliorare il loro codice e non solo a essere un "recensore 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" piuttosto che "Ecco come avrei fatto, ed ecco una patch se sei d'accordo". Suppongo che non sia necessario un DVCS per questo, ma sicuramente aiuta.

Puoi "rileggere" cose che non conosci veramente, ma non puoi esaminarle in modo adeguato. Sono molto competente in C, conosco piuttosto bene il C ++, ma non mi sognerei di recensire qualcosa in C #.

Non credo che tu debba spingersi fino al punto di portare un consulente, dato che alcune aziende sono specializzate nell'esecuzione del tuo codice attraverso un sacco di test e ti dicono cosa potrebbe esserci di sbagliato.

Tuttavia, spetterebbe al singolo sviluppatore che conosce la lingua per interpretare il risultato. Ad esempio, se un recensore di codice mi ha tinto di non usare il valore di ritorno di printf() , li guarderei in modo strano e ne chiedo la sobrietà, poi chiedo "Ok, fantastico, cosa posso fare se non posso stampare nulla console che sarebbe utile? "

Ciò che dovresti prendere in considerazione è parlare con i tuoi dirigenti della creazione di reparti 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 attenzione presteranno attenzione ai dubbi legittimi , anche se eliminano la metà come falsi (come nel mio esempio printf() ).

Fornire una guida su qualcosa che non capisci è simile al cieco che guida il cieco come ben sai.

Un approccio potrebbe essere l'uso di strumenti per la lanuggine come FxCop e StyleCop che affronteranno il fronte dell'analisi statica del codice base. Ciò ti fornirà un punto di partenza per discutere i rapporti generati dagli strumenti.

Un altro approccio sarebbe quello di trasformare le revisioni del codice in revisioni del design. Le revisioni del progetto più spesso poi non scoprono i problemi molto prima che il codice venga persino scritto. Se un programmatore ha un design che 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 subisce un aumento del conteggio degli errori. Cogli i problemi nella revisione del progetto prima che emergano nella revisione del codice, assicurandosi che ognuno di voi abbia una progettazione concreta da implementare; UML è tuo amico qui e strumenti come umlet sono veloci e veloci da usare.

La cattiva notizia è che per partecipare efficacemente alle revisioni del codice, devi 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 comunque utili quando passerai a C #.

Il pensiero che devi tenere sempre presente quando fai la revisione tra pari è:

"SONO IL PROSSIMO UNO PER MANTENERE QUESTO CODICE!"

Devi comprenderlo abbastanza bene da essere in grado di farlo come parte della tua preparazione alla revisione, e il tuo compito è di rendere il programmatore originale consapevole di eventuali carenze che lo rendessero più macchinoso del necessario per capire il codice abbastanza bene per mantenerlo.

Se non puoi programmare in VB, non puoi mantenere il codice e non sei qualificato per essere il peer reviewer.

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

Che cosa puoi fare, seleziona / definisci le linee guida per la codifica e controlla il codice in base a queste linee guida. Quando qualcosa non è conforme alle linee guida puoi chiedere spiegazioni allo sviluppatore.

Vorrei iniziare scegliendo le linee guida esistenti (non conosco gli standard di codifica VB.net ma Google mi ha dato:

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

Utilizza strumenti come stylecop per VB .net

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

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

Una buona revisione del codice riguarda cose che richiedono la comprensione della lingua - uso appropriato della lingua, API e librerie, stile, nomi delle variabili ecc. - e di quanto bene il codice risolva il problema - commenti positivi, architettura corretta , modelli di progettazione pertinenti, considera tutti i casi di errore, ecc. Quando inizi a fare revisioni di codice, tendi a concentrarti sul primo. Sono più facili da vedere e più facili da scegliere. Ad esempio, non mi piacciono i nomi delle variabili. Dovresti utilizzare nomi di stile XXXX.)

La revisione del codice diventa più preziosa quando vi è più attenzione su quanto bene il codice risolva i problemi. Dal momento che non puoi fornire più valore nella prima area ora, concentrati nel fare domande e offrire consigli sulla soluzione del problema, non su come è stato realizzato.

Ovviamente c'è una sovrapposizione tra i due. Conoscere VB.NET ti consente di fornire consigli sul motivo per cui un determinato modello di progettazione non è una buona scelta in una situazione particolare, per esempio.

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

Potresti spostare l'attenzione in modo che si concentri maggiormente sui test anziché sul codice direttamente? Non sto dicendo di abbandonare le revisioni del codice, ma inizialmente potrebbe avere più senso far sì che quelle applicazioni interne abbiano abbastanza test che possano aiutare a decodificare parte di ciò che sta accadendo. L'idea è che i test potrebbero anche aiutarti a familiarizzare un po 'con alcune delle funzionalità. Vedo solo questo come un percorso diverso da prendere. L'idea è che le recensioni tornano più tardi e possono essere fatte in un paio di parti, perché potrebbe essere utile avere una panoramica / sessione iniziale e poi un po 'di pausa. Quella pausa fino al prossimo giorno o due in modo che ci sia abbastanza tempo per chiunque voglia dormire un sonno notturno pensando al codice o qualcosa di simile prima di tornare indietro con le domande e avere una discussione. Detto questo potrebbe non essere sempre realistico, potrebbe valere la pena provare e vedere cosa succede.

Naturalmente se hai già dei test, sfortunatamente non è così significativo. L'altro pensiero è di dare un esempio di dove stanno sostenendo che in VB.Net questo è fatto in un modo particolare, in quanto ciò potrebbe aiutare a rendere questa domanda più chiara in un modo che 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 nozioni di base su VB, l'esecuzione di una revisione del codice senza conoscere tutte le funzionalità della lingua non ti consentirà di rilevare l'utilizzo di funzioni non protette nella lingua.

Supponiamo di non essere a conoscenza del fatto che la funzione input () in Python 2 ha 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 di codice arbitrario, consentendo all'utente di inserire qualcosa come __import__('os').execl('/bin/sh', '/bin/sh') su 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.

Il tentativo di eseguire una revisione del codice senza conoscere tutte le funzionalità della lingua potrebbe non solo impedire di realizzare un modo migliore di eseguire una determinata procedura nella lingua; potrebbe anche portare a difetti di sicurezza dannosi.