Come promuovere la revisione del codice come dipendente? [chiuso]

Non chiamarlo "revisione del codice" quando parli con il tuo capo - che può dare l'impressione di una tecnica molto formale che richiede conoscenze, formazione e strumenti speciali. Chiamalo semplicemente "proof reading" o "four eye principle", e suggerisci di applicarlo a tutto il codice (specialmente al tuo codice) prima che entri in produzione. Non è improbabile quando chiedi a un altro membro del team di rivedere il tuo codice, altri seguiranno il tuo esempio e chiederanno a te (oa qualche altro ragazzo) di rivedere il loro.

Una volta che il tuo team è abituato a una "lettura a prova costante", la necessità di strumenti migliori o di un processo più sistematico probabilmente nascerà da se stessa, quindi è il momento di pensare agli strumenti, non in anticipo.

È bello che tu stia prendendo l'iniziativa per introdurre nuove cose ad una startup - ma se i tuoi fondatori hanno vissuto l'esperienza aziendale nelle loro vite, allora sarebbero diffidenti nei confronti di qualsiasi ' processi "che hanno la tendenza a introdurre la burocrazia in azienda. Un semplice strumento di revisione del codice può evolvere gradualmente in un processo di revisione pre-commit obbligatorio che viene applicato da git hooks!

Devi essere abbastanza scaltro da non implicare alcuna cosa del genere e allontanarti da qualsiasi discussione che si svolga in quel modo - perché, beh, tutti odiano la burocrazia!

Ecco la tecnica che avevo usato una volta:

1. In che modo le persone guardano il loro codice in questo momento?

   Nel mio caso, le persone si scambiavano le e-mail reciprocamente (quindi avevamo già un processo di revisione informale) e poi si vedeva la gente che camminava sulla scrivania dell'altra o scriveva descrizioni poetiche per individuare la parte di codice che vogliono commentare

   In class SomeWeirdClassName, function fooButNotJustFoo() should return a SomeStructInADifferentHeader instead of an int!

   Ora puoi indicare tali casi e dire "Ehi, questo è rotto! Possiamo farlo in un modo migliore!" e poi continua a parlare di come uno strumento di revisione del codice ti consente di aggiungere commenti in linea direttamente su una particolare riga della patch.

2. Inizia con un piccolo gruppo, magari con la tua squadra (puoi costringerli, ehm, convincerli a pranzo) e chiedere loro di evangelizzarlo insieme a te - parlare di come sono fantastiche le cose nella terra di revisione del codice durante tutto riunione di mano.

3. Se hai un ragazzo amministratore, fallo ubriacare il venerdì sera e aggiungi silenziosamente un paio di alias e-mail all'elenco CC di tutte le recensioni. Lunedì, alcune persone avrebbero ricevuto le mail di revisione del codice, con commenti contestuali, collegamenti in tempo reale alla patch e cosa no; quando qualcuno capisce cosa sta succedendo e rimuove quegli alias dalla lista CC. Ma la tua parola è fuori! Ora tutti parlano di "quelle lettere strane che sono finite nella loro casella di posta per errore" - il momento perfetto per il tuo cappello evangelista!

4. Se preferisci parlare direttamente con il tuo capo, assicurati di evidenziare i vantaggi marginali dell'utilizzo dello strumento di revisione del codice:

   a) Le e-mail assicurano che tutti sappiano a cosa sta lavorando ogni altro sviluppatore

   b) Se qualche sviluppatore decide di chiamare malato il giorno del rilascio, non è necessario hackerare su questo computer per ottenere ciò a cui sta lavorando: basta scaricare la patch dallo strumento di revisione del codice e controllarla in te stesso

   c) Inserire frequentemente il codice degli altri nei volti di tutti racchiude il senso della cultura dominante della codifica e spinge tutti a salire sulla stessa barca, invece di seguire religiosamente il proprio stile di codifica

Infine, dal momento che hai già introdotto git (con successo) e le persone sono felici di usarlo, hai già un po 'di credibilità da parte della tua strada - affidati a questa nuova incredibile cosa che cambierà la vita di tutti (per meglio è!!

Be the change you wish to see in the world.
         —Ghandi (bumper stickerized)

Questo tipo di cose tendono ad essere ricevute molto meglio se introdotte volontariamente, quindi volontarie. Crea un gerrit server o simile e inizia a mettere le tue modifiche su di esso. Dì a qualcuno che stai cercando di migliorare la qualità del tuo codice e chiedi se non gli dispiacerebbe rivedere il tuo codice. Quando le persone ti chiedono di rivedere in modo informale il loro codice, richiedi che lo mettano su gerrit. Rendilo aperto a chiunque.

Per lo meno, la qualità del tuo codice migliorerà. Scoprirai a chi importa veramente la qualità del codice e chi è resistente. Vedrai come i tuoi colleghi preferiscono usarlo e può usarlo per creare linee guida se in seguito sarà reso obbligatorio. A livello aziendale, potrebbe continuare all'infinito solo come volontario, o se hai già una squadra disciplinata che fa recensioni informali potresti scoprire che non vale la pena.

Ciò che spesso accade è che una release avrà molti problemi di qualità, la gestione comincerà a scervellarsi su come prevenirla in futuro e cercherà soluzioni. Se hai già in corso questo processo di volontariato che sta già funzionando bene per alcuni, è probabile che a quel punto venga assegnato un supporto di gestione a livello aziendale. Nella mia azienda, il nostro processo agile, i test automatizzati e gli sforzi di modularizzazione sono tutti fondamentalmente iniziati come idee di volontariato.

Se le persone non vogliono che il loro lavoro sia guardato dagli altri perché temono (le ripercussioni delle) critiche, hai un problema ben più grave di una mancanza di revisione del codice.
Il tuo vero problema è un ambiente tossico in cui le persone sono severamente punite per imperfezione e hanno preso l'abitudine di nascondere gli errori, cercare capri espiatori, sorvolare sui problemi. Molto probabilmente è anche un ambiente in cui il successo non è valutato, per non dire ricompensato, perché niente meno che la perfezione è considerato lo standard minimo appena accettabile.

A meno che e fino a quando questa cultura non sia aperta e le persone si sentano libere di discutere dei problemi, parlare apertamente di dove vanno le cose e cosa dovrebbe e può essere fatto per risolverli, la revisione del codice non sarà mai accettata e forzarla sulle persone non farà che guidare a loro trascorrono molto tempo cercando di incolpare gli errori l'uno dell'altro perché sanno perfettamente che nel momento in cui qualcosa viene incolpato su di loro ha un impatto immediato sulla loro carriera.

Per prima cosa devi essere sicuro che tutti sono pronti ad accettare il suo codice da rivedere (in realtà questo può essere il passo più difficile) e lasciare il suo ego da parte.

Quindi puoi promuovere le virtù delle recensioni del codice ai tuoi colleghi (durante il pranzo, ecc.) per fargli capire quali sono i vantaggi delle revisioni del codice. Ti suggerisco di leggere questo articolo.

Quando ritieni che siano pronti per le revisioni del codice, puoi installare uno strumento e iniziare a rivedere il codice dei colleghi (da solo, ma meglio con loro) e assegnare loro i problemi. Riceveranno mail e alla fine completeranno il problema e familiarizzeranno con il sistema e inizieranno a rivedere!