Cosa devo fare quando aspetto una recensione?

So my code is late too.

No, non è il tuo codice, è il codice di te e il senior. Lavori come una squadra, hai una responsabilità condivisa e quando perdi una scadenza, è colpa di entrambi. Quindi assicurati che colui che fa le scadenze lo noti. Se anche quella persona lo vede come un problema, sicuramente parlerà con entrambi voi - questo potrebbe aiutare più di una sola chiacchierata con il vostro collega.

E al tuo EDIT:

I want to be free when coding. How could I gain the trust for development freedom?

La revisione del codice è uno dei più importanti risparmiatori di qualità. È praticamente impossibile scrivere codice eccellente senza un secondo paio di occhi, anche quando hai 20 anni di esperienza di programmazione. Quindi, in una buona squadra, il codice di tutti dovrebbe essere costantemente rivisto: il codice del tuo senior e il tuo codice. Questo non ha nulla a che fare con diffidenza contro di te di persona (o, almeno, non dovrebbe). Finché credi che "la codifica libera" senza un secondo paio di occhi sia migliore, sei ancora un programmatore junior.

In una buona squadra, dovresti avere una coda di compiti di sviluppo assegnati a te in un issue tracker .

In questo modo, mentre aspetti un revisore, potresti ( dovrebbe ) lavorare sull'attività successiva in attesa in quella coda. Una volta che ti sei abituato a lavorare in quel modo, si aprirà un'opportunità per fare rivedere le modifiche in "lotti", riducendo così i ritardi.

• ^{Se non si dispone di una "coda", discuterne con il proprio manager o, meglio ancora, con il revisore. Se la tua squadra non ha un tracker di problemi ragionevolmente conveniente per cose del genere, considera di studiare bacheche di lavoro o opportunità di lavoro interne alla società per trovare una squadra migliore (potresti anche discuterne con il manager / revisore ma non aspettarti che questo aiuti - < a href="http://www.joelonsoftware.com/articles/fog0000000043.html" title="L'articolo" Joel Test "spiega perché è importante - vedi # 4 nella lista"> mancanza di un buon tracker di problemi è spesso un sintomo di qualcosa di gravemente rotto in una squadra).}

I want to be free when coding. How could I gain the trust for development freedom?

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

• ^{Ad esempio, in uno dei miei progetti recenti lo sviluppo è stato svolto da un mini team di me e del mio collega. Ci siamo completamente fidati e rispettati l'un l'altro - ma nonostante ciò abbiamo rivisto il 100% del codice. Lo stavamo facendo perché questo ci consentiva di trovare e correggere rapidamente alcuni bug e, anche molto , perché le recensioni non richiedevano molto tempo e non bloccavano il nostro lavoro.}

Come vedi, sarebbe più accurato pensare alle revisioni del codice in termini di sforzi investiti per prevenire certi rischi . In una buona squadra, puoi aspettarti una sorta di comprensione condivisa su come "bilanciare correttamente" questo. Nota che non esiste un giusto equilibrio valido per tutte le dimensioni, dipende in gran parte da un progetto: rischio e impatto dei bug in un il software mission critical si differenzia naturalmente da quello in un'applicazione non critica.

Utilizzando il tuo esempio, puoi aspettarti di "bloccare le recensioni" purché gli sforzi investiti dal tuo revisore siano giustificati trovando bug e miglioramenti che è meglio correggere prima di applicare il codice.

Probabilmente si aspettano che con la pratica e con le indicazioni ricevute alle recensioni migliorerai la codifica, in modo che trovino sempre meno problemi da risolvere prima del commit. Non appena scoprono che il tuo codice è "abbastanza sicuro" da consentire misure di prevenzione dei rischi meno ingombranti, puoi aspettarti che il processo cambi, ad esempio a recensioni dopo il commit .

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

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

• Se la tua principale preoccupazione è "Mi mancano le scadenze", no. Voi due state congiuntamente mancando le scadenze. Puoi (con sicurezza) dire "Sarò fatto in un'ora, possiamo fare la revisione del codice allora"? Potrebbe essere abbastanza Puoi completare il codice il giorno prima della scadenza? Questo dovrebbe essere un buffer abbondante. Stai completando il tuo codice, con un sacco di buffer tra "si prega di revisione" e la scadenza? Se quest'ultimo, non è nemmeno un difetto comune, direi.

• Il codice dovrebbe sempre essere rivisto. Non riesco a controllare nulla senza (almeno) una seconda serie di occhi e un altro umano che va "OK". Questo vale per i progetti in cui sono il programmatore principale e per i progetti in cui di solito non contribuisco (ma sono riuscito a trovare un bug che mi ha colpito e che ho voluto correggere). Tuttavia, la severità di una recensione si basa molto sulla fiducia. Se ho fiducia che la persona che vuole inviare il codice conosca bene la base di codice, non sarò severa come se non sapessi quanto bene la persona conosca il codice base.

My question is, what should I do? Should I wait him for a review?

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

Un'altra cosa è: il tuo supervisore senior controlla davvero ogni pezzo di codice che fai? Se sì, potresti anche fare la programmazione della coppia.

I want to be free when coding. How could I gain the trust for development freedom?

Ci sono alcune regole che richiedono che i senior controllino il lavoro dei junior (penso che iso 62304 medica lo richieda). Se è così, non puoi fare nulla.

Quello che puoi cambiare è chiedere a senior di non controllare letteralmente tutto. Puoi impostare la procedura di revisione del codice e controllare le cose importanti.

Usa git a livello locale, converti le modifiche in un ramo e avvia il task 2 mentre aspetti. Poi, quando ha finito, puoi unire le sue modifiche al tuo nuovo lavoro e sei già avanti rispetto alla curva nella prossima attività.

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

Una soluzione potrebbe essere quella di coinvolgere lo sviluppatore anziano molto prima con Programmazione coppie sul tuo lavoro.

Pagina di Wikipedia sulla programmazione di coppie

Il vantaggio più ovvio per te è che la revisione avviene molto prima del processo, quindi non devi più attendere lo sviluppatore senior.

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

Potresti avere il problema dello sviluppatore senior che potrebbe non voler associarsi con te. Può essere difficile, ma la mia esperienza è che sia gli sviluppatori senior che i junior guadagnano molta esperienza dalla programmazione pair.

C'è anche spesso la preoccupazione che si metà produttività avendo due sviluppatori che lavorano sullo stesso pezzo di lavoro. È difficile misurare quale sia l'effetto sulla produttività con Pair Programming, la risposta più comune che ho sentito è che la produttività dei team che fanno coppia e quelli che non lo fanno è più o meno la stessa. (Se qualcuno ha saputo qualche buona ricerca su questo mi piacerebbe sentirne parlare)

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

Esamina il tuo codice prima di registrarlo? So che non è il più divertente, ma cerco di farmi fare la maggior parte del tempo. 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 potrebbe almeno fare meglio. Sono d'accordo con il sentimento che il tuo codice dovrebbe sempre essere rivisto e che un secondo set 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 di questi sono grammatica e ortografia inglese, alcuni sono problemi di codifica che il compilatore non cattura. Lo eseguo prima di controllare grandi cambiamenti come cortesia per tutti a valle.

Normalmente permetto alle persone di scrivere il loro codice e occasionalmente mi lamento più tardi, ma non riesame ogni singolo check-in. Una volta ho lavorato con un programmatore molto giovane il cui codice dovevo esaminare e di solito annullare perché hanno commesso tanti errori. Questo non è finito bene. Sei in una professione in cui è spesso più importante farlo in modo giusto che fatto in tempo. Se impari dai tuoi errori, andrai lontano.

Se puoi ridurre al minimo il numero di modifiche che il tuo revisore deve apportare al tuo codice, massimizzi le probabilità che si fidino di te per scrivere codice che non sempre deve essere rivisto con tanta attenzione. Se vuoi la libertà dalle recensioni, prendi la massima responsabilità per la qualità del tuo output.

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

Penso che l'esecuzione di revisioni manuali del codice sia ... beh ... un po 'anni '80. Bene, forse gli anni '90.

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

Andiamo, gente. Ecco a cosa servono changeset (o change list). Fai in modo che i tuoi programmatori sfoghino le fauci fameliche del tuo sistema di controllo del codice sorgente. Quindi il tuo server di integrazione continua inizia con una litania di build mirate (beh, si spera solo la build giornaliera, ma alcuni di noi si lasciano trasportare). Se qualcosa si rompe, metti il trofeo della scimmia del codice (di solito un giocattolo di plastica che qualcuno ha trovato da una scatola di cereali della Lucky Charms) sulla scrivania del perpetratore e tira indietro la lista dei cambiamenti. Bene, alcuni sistemi di integrazione continua cancellano automaticamente notifiche email / IM / desktop a tutti i membri del team / dipartimento / organizzazione che la costruzione è interrotta, insieme a un collegamento ipertestuale elegante per mostrare a tutti chi ha rotto la build in quel file o test. Ora è compito del programmatore sfortunato risolvere qualsiasi cosa abbia rotto il test di compilazione / unit test / integrazione / ecc.

Mentre questo processo viene eseguito, il sistema di revisione del codice entra in azione (di nuovo, attivato dal check-in). Un elenco di membri del team qualificati viene informato dell'elenco delle modifiche impegnato per il controllo del codice sorgente, viene avviata una revisione nel sistema di revisione e tutti iniziano a creare annotazioni per le modifiche nell'elenco delle modifiche. Spero che tutti diranno "LGTM". Se il programmatore è intelligente, si 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 addirittura richiedere che l'elenco delle modifiche venga eseguito il back-out. Sì, i cambiamenti arretrati danneggiano non solo l'ego, ma la mente, è vero. È un buon condimento per gli sviluppatori junior, per reintegrare le liste di modifiche rifiutate.

Se al tuo ambiente di sviluppo manca un CI o un sistema di revisione del codice, dovresti investigare 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 dei test unitari. Se sei uno sviluppatore di C #, cerca qualcosa come NUnit per iniziare.

Gli dici in anticipo quando il codice sarà pronto, non nel momento in cui è stato eseguito. Dovresti essere in grado di determinare che ca. una settimana prima. Questo gli dà il tempo di preparare e pianificare la revisione in modo che si adatti a entrambe le tue pianificazioni.