Peer review o programmazione in coppia, o entrambi?[Chiuso]

Question

• Partecipi a revisioni tra pari del codice o fai pratica di programmazione in coppia, o entrambe?
• Sei riuscito a dimostrare un aumento della qualità del software utilizzando queste pratiche?
• Quali vantaggi e svantaggi hai osservato nel corso della pratica?
• Quali ostacoli hai dovuto affrontare per l'implementazione?

Nel mio caso, il nostro team di sviluppo ha effettuato revisioni tra pari di una serie di diversi artefatti software (analisi dei requisiti, piani di test, codice e così via).La programmazione tra pari non era nemmeno considerata un'opzione.

La pratica della peer review è stata respinta dall’alto e gli sviluppatori non l’hanno mai accettata.Avevamo un gruppo SQA esterno che raccoglieva i parametri dalle attività, ma i numeri erano piuttosto inutili poiché lo sforzo era poco convinto.Dopo anni in cui questo è stato il modo "ufficiale" di fare le cose, gli sviluppatori sono arrivati ​​a ignorare collettivamente le procedure prescritte.

Ora c'è meno visibilità su quando i bug vengono inseriti nel ciclo di vita.E non eseguire le revisioni tra pari ha portato a una maggiore specializzazione del team... dove nessuno conosce veramente i requisiti/la logica dei componenti al di fuori della propria area specializzata del sistema.

Sarebbe utile conoscere le tue esperienze con peer review o programmazione in coppia, in particolare storie di successo.

Answer 1

Quando ero giovane e stupido, uno dei miei primi lavori è stato costruire un parser per estrarre determinati campi in un lungo file PDF che veniva scaricato in testo non formattato.Ne sapevo abbastanza per usare qualche forma di regex, ma non abbastanza per fare bene il lavoro.Diversi giorni dopo ho terminato il compito, ma durante la revisione tra pari sono rimasto schiacciato nell'apprendere che avrei potuto fare meglio e ciò che ho prodotto era spazzatura.Ho imparato a eseguire l'analisi lessicale solo per dimostrare che non ero un idiota, ma diciamo solo che il processo di revisione tra pari ha fatto schifo.Non avevo bisogno di una persona anziana che danzasse sui miei fallimenti, avevo bisogno di un mentore e me lo sono ricordato ogni volta che ho fatto una revisione tra pari.

Mi piacciono le revisioni tra pari quando controlliamo gli ego alla porta.(Questo include il mio!) C'è una quantità limitata di tempo in questo mondo e solo così tanto che puoi imparare e fare.Attraverso una buona revisione tra pari puoi ampliare le tue conoscenze e ottenere di più in un arco di tempo più breve.I problemi sorgono quando le cose si riducono a un controllo eccessivo della sintassi anale.

Ho alcune regole per questo motivo.Non eseguo la peer review di nulla che possiamo automatizzare.Esegui un controllo ortografico e un abbellitore di codice.Se hai a disposizione qualcosa come FXCop, eseguilo, fai quello che dice o hai una buona ragione per cui non lo sei.Quindi possiamo vedere come è messo insieme il codice, come funziona e cosa possiamo fare per migliorarlo.In questo modo ottieni una prospettiva diversa su come risolvere un problema e perché qualcuno la pensa in quel modo.A volte il contrario non è proprio migliore, a volte la nuova soluzione è fantastica e qualcosa che utilizzerai per il resto della tua vita di programmazione.Una volta terminata la revisione, basta, non la userò come esempio contro di te.Sta a te imparare cosa vuoi da esso.Non ce la farò con la paura o la minaccia, sei una persona intelligente e te lo lascerò dimostrare.

Answer 2

Cerchiamo di assicurarci che nessun codice entri in produzione senza essere passato attraverso almeno un altro paio di occhi.
Di solito significa che eseguiamo la revisione del codice.Cerchiamo di rendere un'abitudine nel team il fatto che le revisioni siano una parte intrinseca della scrittura del codice.Lo scrivi e poi chiedi a qualcuno un parere.
Inoltre, nei progetti in cui abbiamo abbastanza persone disponibili (quando i compiti sono della giusta dimensione) proviamo ad accoppiare la programmazione.
Devo dire che abbiamo visto sicuramente un vantaggio in questo.Prima di tutto, è un ottimo modo per fare da mentore agli sviluppatori junior nel team: quando rivedi il loro codice puoi mostrare loro cosa può essere fatto meglio e, quando si accoppiano con loro, possono vedere modi migliori di fare le cose, come le persone esperte pensare e anche come utilizzare meglio l'IDE.
Inoltre, mantiene sincronizzato l'intero team per quanto riguarda la conoscenza dell'aspetto del codice.
E, inoltre, aumenta semplicemente la gioia e lo sviluppo personale di tutti: un team capace di parlare e ragionare sul codice è un team migliore, un team che continua ad apprendere e condividere.

Alcune cose a cui prestare attenzione:

• Assicurati che gli anziani lascino programmare anche i ragazzi durante l'abbinamento
• Non lasciare che le persone si associno a piccoli compiti, di solito fa perdere tempo
• Guarda come vanno d'accordo le coppie (non forzare una coppia insieme)
• Ricordatevi di rimescolare le coppie di tanto in tanto
• Non lasciare che le recensioni siano in contrasto con l'ego: non lasciare che le persone schiaccino gli altri

Answer 3

La revisione tra pari dovrebbe esserlo OBBLIGATORIO.

Puoi leggere e trovare numerosi articoli e libri che discutono diversi modi per affrontare questo problema all'interno di team di varie dimensioni, ma sembra che tu stia chiedendo informazioni sulle esperienze.

Personalmente, penso che la peer review dovrebbe essere resa divertente.Il cibo fornito e mantiene l'atmosfera gioviale.Dovrebbe davvero essere trattato come un momento in cui gli sviluppatori/programmatori possono imparare gli uni dagli altri e non avere la possibilità di giudicare (e sappiamo tutti come ogni programmato sembra nato con un gene giudicante innato).Ho avuto la tendenza ad apprezzare o ad aiutare a organizzare le recensioni in modo che fossero aperte per 1/3 o 1/4 delle volte.Con questo intendo quando il gruppo si riunisce e una persona presenta un progetto a cui sta lavorando o addirittura ha rivisto che non è nemmeno correlato al progetto attuale (so che è difficile con le scadenze, ma provaci).

I creativi di solito si riuniscono per esporre dipinti, disegni e artisti a cui si dedicano attualmente per facilitare l'ispirazione.Realisticamente, l’ispirazione dovrebbe essere il concetto principale che speri di promuovere in una recensione.In secondo luogo, le persone notano naturalmente cose che fanno i loro colleghi sviluppatori che NON avevano notato prima.“Oh wow, quindi sei riuscito a farlo con una singola riga di codice?Fantastico." Ispirare e motivare gli sviluppatori su ciò che fanno, su cosa stanno lavorando e su come lo fanno pagherà di più rispetto all'utilizzo della revisione paritaria per stabilire l'ordine gerarchico e il rango.

Infine arriva la parte vera e propria della “recensione”, ma è un fatto inevitabile.I tuoi sviluppatori migliori vedranno un codice scadente e dopo un numero sufficiente di revisioni è tempo che il programmatore scadente faccia un passo avanti o se ne dimentichi.

Se mantieni le cose positive e organizzate, di solito è una bella esperienza.

Quasi dimenticavo di toccare la programmazione della coppia.Questo è più difficile da configurare.Ovviamente non puoi avere due dei tuoi programmatori più deboli che lavorano insieme o potresti anche organizzare un milione di scimmie con un milione di macchine da scrivere.Prova a mettere una persona più forte con una più debole e offri incentivi a entrambi in privato.Qualcuno che è più debole dovrebbe sapere che il miglioramento potrebbe essere ricompensato (se richiede tale incentivo) e il programmatore più forte dovrebbe sapere che i veri leader iniziano come buoni mentori.Assicurati però che lo sviluppatore più debole stia digitando.Non viceversa altrimenti diventa una presentazione e"sbadiglio" qualcuno potrebbe non guadagnare nulla dall'esperienza.

Answer 4

Ho svolto un sacco di coaching agile e per aiutare le persone a superare lo "stigma" della programmazione in coppia, lo chiamiamo "revisione del codice e del progetto in tempo reale".Le persone sembrano comprendere meglio il concetto se lo metti in questi termini.

Answer 5

L'unica esperienza direttamente correlata che ho con entrambi è quella delle revisioni di progettazione tra pari (molto tempo fa).E facevano schifo.Se si legge la letteratura, era chiaro che infrangevano diverse regole di buone recensioni (saltare addosso alle persone, concentrarsi sull’ortografia, nessun risultato chiaro ecc.ecc.) ma era tutto ciò che sapevamo.

MA da allora sono stato coinvolto in numerose revisioni del codice offline.

A seconda del progetto, hanno ricevuto l'incarico prima di effettuare il check-in nella filiale "live" o in un momento successivo casuale.In 3 progetti su 4 sono stati accolti, inizialmente come un male necessario, ma in seguito come un input prezioso.

Il vantaggio di qualsiasi revisione operativa dovrebbe essere quello di far sì che tutti scrivano codice migliore e di fornire tutoraggio anche ai migliori programmatori (sii onesto, i tuoi programmatori di punta scrivono effettivamente codice leggibile?) Una volta che riesci a persuadere il personale meno esperto a dire che non lo fanno capisci qualcosa: sei lontano.Alcuni degli scatti più interessanti sbufferanno, ma i migliori penseranno a ciò che hanno scritto e cambieranno effettivamente i nomi delle variabili o il layout - e forse aggiungeranno anche un commento.

Il quarto progetto utilizza uno schema imposto di revisione "in un momento casuale" e i responsabili tecnici non sono ancora intervenuti (team rotto?)

---

Le due pratiche che descrivi sono approcci formali.Non funzionano bene per tutte le personalità e i gruppi.

Prova qualcosa che ritieni che la tua squadra possa effettivamente fare e poi vedi se può essere migliorato.

Una volta che avrai avuto quel paio di occhi in più sul tuo codice, non vorrai guardare indietro

Answer 6

• Sì, la nostra azienda utilizza le revisioni del codice tra pari.Li conduciamo come revisioni Over-The-Shoulder e invitiamo il tester del team a partecipare alla riunione per acquisire una migliore comprensione dei cambiamenti.

• La revisione del codice presenta indubbi vantaggi, come diversi studi hanno potuto dimostrare.Per la nostra azienda, era evidente che la qualità del codice aumentava man mano che diminuiva il numero di chiamate di supporto e diminuiva anche il numero di bug segnalati.NOTA:Alcuni dei vantaggi qui sono stati il ​​risultato dell'implementazione di Scrum e dell'abbandono di Waterfall.Maggiori informazioni su Scrum di seguito.

• I vantaggi della revisione del codice possono essere un prodotto più stabile, un codice più manutenibile poiché si applica alla struttura e agli standard di codifica e consente agli sviluppatori di concentrarsi maggiormente sulle nuove funzionalità piuttosto che sui bug "antincendio" e su altri problemi di produzione.Non ci sono davvero svantaggi se le revisioni del codice vengono condotte “nel modo giusto”.Maggiori informazioni sulla "strada giusta" di seguito.

• Alcuni degli ostacoli da superare durante l'implementazione delle revisioni del codice sono l'idea che il “fratello maggiore” mi osserva e l'idea che non avere un codice perfetto significhi tortura e dolore.Convincere gli sviluppatori a fidarsi l'uno dell'altro a volte è difficile, soprattutto quando si tratta di "ordine gerarchico" o di atteggiamenti "più santi di te" e di mettere il proprio duro lavoro al microscopio.La fiducia è la chiave per risolvere questi problemi.Uno sviluppatore deve avere fiducia che non sarà punito dai colleghi o dal management per errori nel codice.Succede a tutti.Prendi nota del problema, risolvilo e vai avanti.

MischiaUno dei vantaggi derivanti dall’utilizzo della metodologia Scrum è che il ciclo di sviluppo (“sprint”) è breve.L'intervallo di tempo dello "sprint" è determinato da ciò che funziona meglio per la tua organizzazione e richiederà alcuni tentativi ed errori, ma in realtà non dovrebbe durare più di quattro settimane di iterazioni.Il vantaggio è che richiede che gli sviluppatori comunichino quotidianamente e comunichino i problemi nelle prime fasi del progetto.Questo è stato inizialmente adottato dal nostro dipartimento di sviluppo e si è diffuso a tutte le aree della nostra azienda poiché i vantaggi di Scrum sono di vasta portata.Per ulteriori informazioni, vedere: http://en.wikipedia.org/wiki/SCRUM O http://www.scrumalliance.org/ .Poiché le iterazioni di sviluppo sono più piccole, il processo di revisione del codice esamina parti di codice più piccole, aumentando le probabilità che la revisione rilevi problemi rispetto a ore o giorni di revisioni formali.

"Giusta direzione"Le revisioni del codice eseguite nel “modo giusto” sono completamente soggettive.Tuttavia, personalmente ritengo che dovrebbero essere revisioni informali e generali.Tutti i partecipanti a una recensione dovrebbero evitare di attaccare personalmente la persona recensita con affermazioni come "perché l'hai fatto in quel modo?" o "a cosa stavi pensando?" ecc.Questi tipi di commenti diminuiscono la fiducia tra colleghi, portando ad animosità e ore di discussioni sul modo migliore/giusto per codificare una soluzione.Tieni presente che gli sviluppatori non pensano o codificano esattamente allo stesso modo e ci sono molte soluzioni a un problema.
Solo un piccolo chiarimento sulle recensioni over-the-shoulder;questi possono essere condotti tramite la condivisione del desktop remoto (scegli il sapore qui) o di persona.Tuttavia, non dovrebbero essere limitati solo agli sviluppatori.In genere invitiamo il nostro intero team Scrum, composto da due sviluppatori per team, un tester, una persona che si occupa della documentazione e il proprietario del prodotto.Tutti i non sviluppatori sono lì per acquisire una migliore comprensione delle modifiche o delle nuove funzionalità apportate.Sono liberi di porre domande o fornire input, ma non di prendere decisioni o commenti sulla codifica.Ciò è stato efficace in quanto verranno poste alcune domande che potrebbero cambiare la direzione del progetto poiché i requisiti iniziali potrebbero aver mancato uno scenario, ma questo è l'agile, il cambiamento.

SuggerimentoConsiglio vivamente di ricercare scrum e revisioni del codice, prima di imporli.Crea le regole di base per ciascuno e implementale come parte della tua cultura per ottenere un prodotto di migliore qualità.Deve diventare parte della tua cultura in modo che sia parte di un processo naturale e integrato a tutti i livelli, poiché rappresenta un cambiamento di paradigma da scarsa qualità, scadenze mancate e frustrazione a prodotti di migliore qualità, meno frustrazione e risultati più puntuali .

Answer 7

Un'analisi comparativa dopo essere passati alle revisioni PR su github dalla programmazione in coppia.

L'obiettivo è elencare passo dopo passo ciò che i nostri team seguono ora nel processo di revisione delle PR.

"Recensioni del codice vs programmazione in coppia" https://blog.mavenhive.in/pair-programming-vs-code-reviews-79f0f1bf926