Cosa devo fare quando aspetto una recensione?

Prima di porre la mia domanda, devo spiegare la situazione.

Sto lavorando per un'azienda come ingegnere informatico junior. Uno degli anziani mi ferma sempre quando ho finito il mio sviluppo e voglio impegnarmi.

Vuole sempre che aspetti che lo riveda. Questo va bene, perché di solito trova alcuni bug e fa alcune ottimizzazioni.

Tuttavia, devo impegnare il mio codice prima della scadenza. Quando ho finito, lo chiamo e dico che è finito. Di solito arriva in ritardo. Quindi anche il mio codice è in ritardo.

La mia domanda è: cosa devo fare? Dovrei aspettarlo per una recensione?

EDIT: aggiunta alla domanda. Sono curioso di sapere un altro problema.

Voglio essere libero durante la programmazione. Come potrei guadagnare la fiducia per la libertà di sviluppo?

_{Alcune spiegazioni: ne ho parlato con lui. Ma non ha aiutato. Usiamo già un tracker di problemi, ma non ci sono attività per le recensioni. Ci sono solo attività di sviluppo e test.}

Quindi anche il mio codice è in ritardo.

No, non è il tuo codice, è il tuo codice e quello senior. Lavori in gruppo, hai una responsabilità condivisa e quando perdi una scadenza, è colpa di entrambi. Quindi assicurati che chi nota le scadenze se ne accorga. Se anche quella persona lo vede come un problema, sicuramente parlerà con entrambi, il che può aiutare più di una sola chiacchierata con il collega.

E al tuo EDIT:

Voglio essere libero durante la programmazione. Come potrei guadagnare la fiducia per la libertà di sviluppo?

La revisione del codice è uno dei più importanti risparmiatori di qualità. È praticamente impossibile scrivere un codice eccellente senza un secondo paio di occhi, anche quando si hanno> 20 anni di esperienza di programmazione. Quindi, in una buona squadra, il codice di tutti dovrebbe essere costantemente rivisto - il codice del tuo senior così come il tuo codice. Questo non ha nulla a che fare con la sfiducia nei tuoi confronti di persona (o, almeno, non dovrebbe). Finché credi che "codificare gratis" senza un secondo paio di occhi sia meglio, sei ancora un programmatore junior.

In una buona squadra, dovresti avere una coda di attività di sviluppo assegnate a te in un tracker di problemi .

In questo modo, mentre aspetti un revisore, potresti ( dovresti ) lavorare sulla prossima attività in attesa in quella coda. Una volta che ti abitui a lavorare in quel modo, questo aprirà l'opportunità di rivedere le tue modifiche in "lotti", riducendo così i ritardi.

• ^{Se non si dispone di una tale "coda", discuterne con il proprio responsabile o, meglio ancora, con il revisore. Se il tuo team non ha un tracker dei problemi ragionevolmente conveniente per cose del genere, prendi in considerazione lo studio di schede di lavoro o opportunità di lavoro interne all'azienda per trovare un team migliore (potresti anche discuterne con il manager / revisore ma non aspettarti che ciò aiuti - mancanza di un buon tracker di problemi è spesso un sintomo di qualcosa di gravemente rotto in una squadra).}

Voglio essere libero durante la programmazione. Come potrei guadagnare la fiducia per la libertà di sviluppo?

Per scoprirlo, devi prima capire lo scopo delle revisioni del codice. Hai citato la fiducia - questa è una buona "approssimazione", ma non del tutto accurata.

• ^{Ad esempio, in uno dei miei recenti progetti lo sviluppo è stato fatto da un mini team di me e il mio collega. Ci siamo fidati e ci siamo rispettati reciprocamente, ma nonostante ciò abbiamo esaminato il 100% del codice. Lo stavamo facendo perché questo ci ha permesso di trovare e correggere rapidamente alcuni bug e, il che è anche molto importante, perché le recensioni non hanno richiesto molto tempo e non hanno bloccato il nostro lavoro.}

Vedete, sarebbe più accurato pensare alle revisioni del codice in termini di sforzi investiti per prevenire determinati rischi . In una buona squadra, puoi aspettarti una sorta di comprensione condivisa su come "bilanciare correttamente" questo. Nota che non esiste un equilibrio adeguato per tutte le dimensioni, dipende in larga misura da un progetto: il rischio e l'impatto dei bug in un software mission-critical differisce naturalmente da quello di un'applicazione non critica.

Usando il tuo esempio, puoi aspettarti di "bloccare le recensioni" fintanto che gli sforzi investiti dal tuo revisore sono giustificati dalla ricerca di bug e miglioramenti che dovrebbero essere corretti prima di commettere il tuo codice.

Probabilmente si aspettano che con la pratica e con la guida ricevuta durante le recensioni migliorerai nella codifica, in modo da trovare sempre meno problemi che vale la pena risolvere prima di impegnarsi. Non appena scoprono che il tuo codice è diventato "abbastanza sicuro" per consentire "misure di prevenzione del rischio" meno ingombranti, puoi aspettarti che il processo cambi, ad esempio le revisioni dopo il commit .

A seconda di un progetto, ad un certo punto il tuo codice potrebbe persino essere considerato abbastanza sicuro da saltare le recensioni, lasciando la scoperta dei bug ai tester (ma ciò non accadrà necessariamente, vedi il mio esempio sopra).

Ci sono più risposte possibili qui, a seconda di quale sia esattamente il tuo problema.

• Se la tua principale preoccupazione è "Mi mancano le scadenze", no. A voi due mancano le scadenze insieme. Puoi (con fiducia) dire "tra un'ora sarò finito, allora possiamo fare la revisione del codice"? Questo potrebbe essere abbastanza. Puoi completare il codice il giorno prima della scadenza? Dovrebbe essere un buffer abbondante. Stai completando il tuo codice, con un sacco di buffer tra "si prega di rivedere" e la scadenza? Se quest'ultimo, non è nemmeno un difetto comune, direi.

• Il codice deve sempre essere rivisto. Non riesco a controllare nulla senza (almeno) una seconda serie di occhi e un altro essere umano "va bene". Questo vale per i progetti in cui sono il programmatore principale, nonché per i progetti in cui normalmente non contribuisco (ma sono riuscito a trovare un bug che mi ha influenzato e che voglio correggere). Tuttavia, la rigidità di una recensione si basa molto sulla fiducia. Se mi fido che la persona che desidera inviare il codice conosca bene la base di codice, non sarò così severa come se non sapessi quanto bene la persona conosce la base di codice.

La mia domanda è: cosa devo fare? Dovrei aspettarlo per una recensione?

No, non dovresti semplicemente restare inattivo. C'è sempre qualcosa da fare. Come suggerito da Gnat , dovrebbe esserci una fila di attività. Oppure, in modo agile di sviluppo, un elenco di attività assegnate all'utente per l'attuale iterazione. Se ti siedi inattivo, c'è qualcosa di sbagliato nell'organizzazione della tua azienda o del tuo team.

Un'altra cosa è: il tuo supervisore senior sta davvero controllando ogni pezzo di codice che fai? In caso affermativo, è anche possibile eseguire la programmazione in coppia.

Voglio essere libero durante la programmazione. Come potrei guadagnare la fiducia per la libertà di sviluppo?

Ci sono alcuni regolamenti che richiedono che il senior controlli il lavoro del junior (penso che il medico iso 62304 lo richieda). Se è così, non puoi fare nulla.

Quello che puoi cambiare è chiedere a senior di non controllare letteralmente tutto. È possibile impostare il processo di revisione del codice e controllare le cose importanti.

Usa git localmente, esegui il commit delle modifiche in un ramo e inizia l'attività 2 mentre aspetti. Quindi quando ha finito, puoi unire le sue modifiche al tuo nuovo lavoro e sei già in anticipo sulla curva del compito successivo.

Fallo abbastanza a lungo e abbastanza presto, può rivedere 2 o più cose in una sola seduta. Scegli cose in cui è improbabile che le linee si sovrappongano per ridurre al minimo i conflitti.

Una soluzione a questo potrebbe essere quella di coinvolgere lo sviluppatore senior molto prima con Pair Programming sul tuo lavoro.

Pagina di Wikipedia sulla programmazione delle coppie

Il vantaggio più ovvio per te sarebbe che la revisione avviene molto prima nel processo, quindi non devi più aspettare lo sviluppatore senior.

Oltre a questo, sarai in grado di vedere i processi e le tecniche di pensiero dello sviluppatore senior mentre scrive il codice e imparare da questo.

Potresti avere il problema dello sviluppatore senior potrebbe non voler accoppiarti con te. Questo può essere difficile, ma la mia esperienza è che sia gli sviluppatori senior che quelli junior acquisiscono molta esperienza nella programmazione di coppie.

Spesso c'è anche la preoccupazione che si dimezzerà la produttività facendo lavorare 2 sviluppatori sullo stesso lavoro. È difficile misurare quale sia l'impatto sulla produttività con Pair Programming, la risposta più comune che ho sentito è che la produttività dei team che si accoppiano e quelli che non lo fanno è più o meno la stessa. (Se qualcuno ha qualche buona ricerca su questo mi piacerebbe sentirne parlare)

Non una risposta completa da sola, solo un'aggiunta alle eccellenti risposte sopra ...

Esamini il tuo codice prima di registrarlo? So che non è il più divertente, ma cerco di farmi fare la maggior parte delle volte. Ho programmato professionalmente per 20 anni (34 anni in totale), ma di solito trovo almeno un bug e / o una cosa che ho dimenticato, o che potrei almeno migliorare. Sono d'accordo con il sentimento che il tuo codice dovrebbe sempre essere rivisto e che una seconda serie di occhi è migliore di una coppia. Ma anche la stessa coppia che supera il codice due volte è meglio di una volta.

Scrivi test unitari per il tuo codice? Oltre ai test unitari, ho anche un piccolo script di shell che cerca gli errori più comuni che faccio personalmente. Alcuni sono grammatica inglese e ortografia, altri sono problemi di codifica che il compilatore non rileva. Lo eseguo prima di effettuare il check-in di grandi modifiche per gentile concessione di tutti a valle.

Di solito lascio che le persone scrivano il loro codice e occasionalmente lo lamentano, ma non riesco a controllare ogni singolo check-in. Una volta ho lavorato con un programmatore molto giovane il cui codice ho dovuto rivedere e di solito annullare perché hanno fatto così tanti errori. Non è finita bene. Hai una professione in cui è spesso più importante farlo nel modo giusto che in tempo. Se impari dai tuoi errori, andrai lontano.

Se riesci a ridurre al minimo il numero di modifiche che il tuo revisore deve apportare al tuo codice, massimizzi la possibilità che si fidino di te per scrivere codice che non sempre deve essere rivisto così attentamente. Se desideri essere libero dalle recensioni, prenditi la massima responsabilità per la qualità del tuo output.

Alcuni o tutti questi suggerimenti potrebbero essere fatti in attesa che qualcun altro riveda il tuo codice.

Penso che eseguire revisioni manuali del codice sia ... beh ... un po 'anni '80. Beh, forse anni '90.

In questa era moderna di integrazione continua e sistemi di revisione del codice online, non si vuole davvero trattenere alcun commit del codice solo perché si teme che "potrebbe interrompere il controllo del codice sorgente".

Andiamo gente. Ecco a cosa servono i changeset (o gli change list). Fai in modo che i tuoi programmatori nutrano le fauci affamate del tuo sistema di controllo del codice sorgente. Quindi il tuo server di integrazione continua entra in gioco con una serie di build mirate (beh, si spera solo la build giornaliera, ma alcuni di noi vengono portati via). Se qualcosa si rompe, metti il ​​trofeo della scimmia codice (di solito un giocattolo di plastica che qualcuno ha trovato da una scatola di cereali Lucky Charms) sulla scrivania dell'autore del reato, e ripristina l'elenco delle modifiche. Bene, alcuni sistemi di integrazione continua inviano automaticamente notifiche e-mail / messaggistica istantanea / desktop a tutti i membri del team / dipartimento / organizzazione che la build è interrotta, insieme a un elegante collegamento ipertestuale per mostrare a tutti coloro che hanno rotto esattamente la build in quale file o test. Ora è il programmatore sfortunato

Durante l'esecuzione di questo processo, il sistema di revisione del codice si avvia (di nuovo, attivato dal check-in). Un elenco di membri qualificati del team viene informato dell'elenco di modifiche impegnato nel controllo del codice sorgente, una revisione viene avviata nel sistema di revisione e tutti iniziano a scrivere annotazioni sulle modifiche nell'elenco delle modifiche. Eventualmente tutti diranno "LGTM". Se il programmatore è intelligente, ricorderà di pregare / corrompere / nascondere. Se ci sono problemi seri, i revisori possono creare un difetto (che può essere agganciato al sistema di tracciamento dei bug), o persino richiedere il backup dell'elenco modifiche. Sì, i cambiamenti arretrati hanno danneggiato non solo l'ego, ma la mente, è vero. È un buon condimento per gli sviluppatori junior, per reintegrare le liste di modifiche rifiutate.

Se nel tuo ambiente di sviluppo manca un elemento della configurazione o un sistema di revisione del codice, dovresti indagare seriamente su questi. Un paio di link potrebbero aiutarti:

Atlassian Crucible
JetBrains TeamCity
reitveld
Cruise Control

Se hai intenzione di ottenere un server CI, dovresti anche pensare seriamente ai framework di unit test. Se sei un sviluppatore C #, cerca qualcosa come NUnit per iniziare.

Gli dici in anticipo quando il tuo codice sarà pronto, non nel momento in cui è finito. Dovresti essere in grado di determinare che ca. una settimana in anticipo. Ciò gli dà il tempo di preparare e pianificare la revisione in modo che si adatti a entrambi i tuoi progetti.