Sono richieste pull il posto per l'addestramento juniores

Abbiamo un concetto secondo cui tutto il codice in una richiesta pull in master dovrebbe essere pronto per la produzione. Questo ha senso ed è un'affermazione equa secondo me.

L'idea qui è che una volta creato il PR, stai affermando che avresti messo questo in master, ma vorresti che alcuni revisori si limitassero a "concordare" con te e individuare ciò che ti manca.

Dato che siamo solo umani, facciamo errori e speriamo che altri revisori possano trovare elementi che i test unitari non sono riusciti a trovare: errori di ortografia, javadocs errati ecc.

MA, una richiesta pull è il luogo in cui dovremmo fornire un certo livello di assistenza / formazione agli sviluppatori e, in tal caso, a quale livello?

Ogni volta che si spingono nuove modifiche, i revisori devono riesaminare le modifiche, che prendono dal loro tempo di sviluppo e causano la revisione delle modifiche.

Quindi, quanta formazione è prevista, dovrebbe essere consentita, nelle richieste pull? Parte di me sente che varia da junior a senior. Tuttavia, sento anche che non dovrebbe essere il posto giusto per trovare grandi quantità di problemi, anche per i giovani.

Qualcun altro sta cercando di convincere gli sviluppatori a raggiungere l'obiettivo di "La mia richiesta pull dovrebbe essere pronta per la produzione"?

No. Le richieste pull non sono il luogo adatto per la formazione. La tua squadra ha l'idea giusta. Un PR significa "Penso che sia bello andare. Posso avere un secondo set di occhi su questo nel caso in cui avessi perso qualcosa. Sono umano dopo tutto." E sospetto che sia esattamente quello che sta facendo il tuo apprendista. Onestamente pensano che sia bello andare.

Ecco un'idea estrema (gioco di parole inteso). Associa il programma all'apprendista che ti sta dando il bruciore di stomaco. Come membro del team più senior, è tuo compito sollevarli e renderli produttivi.

Se il codice che viola i principi di progettazione di base o gli standard del team arriva alla fase di richiesta pull, dovrebbe essere sicuramente indirizzato lì. E le revisioni del codice possono essere un buon mezzo per comunicare gli standard e le pratiche di progettazione del team.

Ma è il posto migliore? Ecco alcuni motivi per cui direi di no:

1. Se sono necessarie diverse iterazioni di revisione del codice per affrontare un difetto di progettazione fondamentale o un problema su larga scala, allora ci sarà una forte tentazione di trascurare i problemi più piccoli di cui sopra, a causa di scadenze o esaurimento generale con la recensione. Idealmente, la squadra sarebbe abbastanza resistente per resistere a questa tentazione, ma probabilmente è meglio non creare una situazione che lo porterebbe.
2. Ricevere una revisione del codice con un gran numero di commenti non è una grande esperienza per uno sviluppatore junior / nuovo assunto. Sì, rispondere al feedback è un'abilità che dovranno sviluppare, ma è anche vero che gli sviluppatori non sono sempre in grado di rispondere con tatto al codice che non gli piace.

Le revisioni di programmazione e progettazione delle coppie sono luoghi preferibili per feedback su larga scala.

Detto questo, sarebbe anche peggio lasciare passare il codice per paura che affrontarlo durante le revisioni del codice sia "sbagliato", e potrebbero esserci alcune circostanze (ad esempio squadre remote) in cui questo è il meglio che puoi fare. In tal caso, risolvi i problemi nella revisione del codice e risolvi anche i problemi nel tuo processo di sviluppo che è arrivato così lontano.

Mentre trovare il problema durante una richiesta pull potrebbe non essere l'ideale, è certamente meglio che nei test o in un problema di produzione.

Lo direi di più perché le richieste pull non dovrebbero essere l' unico posto in cui si allena la gente. Inoltre, gli sviluppatori junior non sono gli unici che potrebbero aver bisogno di formazione in una richiesta pull. Appaltatori, collaboratori open source, sviluppatori di altri dipartimenti che non hanno familiarità con il codice o gli standard locali e persino i programmatori veterani hanno bisogno di promemoria occasionali quando diventano compiacenti.

Per un po 'di tempo, la richiesta di pull è aperta a costi molto bassi. Fornisci il numero di feedback che desideri a quante più persone desideri, quindi lascialo in pace fino a quando gli autori ti notificano di nuovo che pensano che sia pronto per la fusione. Una richiesta pull è un ottimo strumento centrale per comunicare sulle modifiche al codice proposte, siano esse completamente pronte o necessitino di molto lavoro.

Alcune revisioni delle richieste di pull risultano poco più che un timbro di gomma, e alcune che sono invii esterni a una squadra potrebbero richiedere un mese avanti e indietro. Il primo tipo è bello quando puoi ottenerlo, ma ciò non significa che il secondo tipo non sia prezioso. Cercare di indurre le persone a inviare richieste pull perfette in ogni momento sarà frustrante per tutti.

Ho sempre pensato che uno dei tratti distintivi di un buon vantaggio sia qualcuno che fornisce l'addestramento aggiuntivo necessario in ogni ciclo di sviluppo. Per me, ciò significa che non sto solo codificando me stesso o rivedendo il codice, ma seduto con altri sviluppatori junior, accoppiare la programmazione con loro per aiutarli a evitare il tipo di mine antiuomo che ho calpestato.

Principalmente, non ho l'illusione che il nostro obiettivo primario sia educativo, non lo è. Che tu sia un senior, un lead o uno sviluppatore junior, l'obiettivo non è la tua edificazione. L'obiettivo è sempre quello di fornire al cliente un codice di qualità. Preferibilmente in tempo, a budget, facendo quello che vogliono. Riconosco, tuttavia, che è impossibile per me portare a termine tutto il lavoro da solo, quindi spetta a me essere un vantaggio per aiutare tutti ad aiutare il team ad avere successo. Ciò significa riconoscere le opportunità di formazione quando appaiono in natura.

Quindi, alla tua domanda sul fatto che le richieste pull siano il posto giusto per allenare i giovani, dovrei dire che non è raro che durante questi momenti sorgano momenti insegnabili. Ehi, dovrai affrontare il tuo primo conflitto di unione, andiamo oltre dopo la revisione. Oh guarda, non hai incluso nessun test unitario per il tuo DAO, rimanderemo la tua recensione fino a quando non avremo avuto la possibilità di coprire quei nuovi metodi. Perché hai pensato che sarebbe meglio usare le doppie primitive in questo calcolo finanziario rispetto a BigDecimals? Sì, non è insolito.

Quindi, mentre direi che certamente può succedere, ma chiaramente non è l'obiettivo principale di una richiesta pull. Né ritengo ci sia l'aspettativa che il codice in una richiesta pull sia pronto per la produzione. Spesso non lo è.

Se stai usando funzionalità e rilasci di rami in una strategia di ramificazione in stile gitflow, le tue richieste pull diventano qualcosa di più simile ai candidati al rilascio. Non pronto per la produzione, ma qualcosa di più approssimativo. Sai che il tuo codice viene compilato (a destra) e hai una prova di prova sufficiente per affermare che soddisfa gli obiettivi della storia dell'utente. E poiché hai già eseguito diversi test di integrazione nel tuo ambiente di sviluppo, hai una grande demo pronta per partire se ti viene chiesto di dimostrare le tue modifiche, cosa che farai, durante la revisione del tuo PR.

In definitiva, ritengo che dovremmo fornire assistenza durante le revisioni del PR, ma l'assistenza non riguarda la codifica generale. Al contrario, è associato alla preparazione del codice proposto per l'inclusione con una base operativa di codice di qualità di produzione. Il PR è un'opportunità per gli sviluppatori di dimostrare di avere una giustificazione e una solida comprensione di ogni modifica che hanno incluso nel PR. E anche allora - anche dopo averli appesantiti con test unitari, dimostrazioni e un sacco di domande - non ci si può aspettare che le modifiche proposte siano pronte per la produzione.

Il codice è vicino dopo tutto ciò. Ma poi permettiamo al QA di torturarlo.

Voglio ringraziare tutti per il loro contributo e aiutarmi a capire cosa hanno da dire le persone su questo argomento.

Questa è la mia risposta dopo il feedback dato e la mia comprensione ora si basa sulle risposte e sui commenti ricevuti. Grazie a tutti.

Sommario

• Non aspettarti o applicare richieste di pull perfette del pipistrello in quanto ciò diventerà frustrante solo per tutti i soggetti coinvolti.
• Ma continua a renderlo il nostro obiettivo per richieste pull perfette.
• Aspettati un po 'di collaborazione / assistenza nelle richieste pull. Dopotutto, questo è ciò che stai essenzialmente richiedendo creando una richiesta pull.
• Se diventa un po 'eccessivo a causa di difetti di progettazione o di implementazione, trascorri del tempo con quello sviluppatore e fai un po' di programmazione di coppie per costruirli e avvicinare il loro codice all'obiettivo . Questo è il ruolo di tutti gli sviluppatori senior.
• Gli junior avranno bisogno di più sessioni di programmazione delle coppie rispetto agli sviluppatori intermedi. Quindi aspettati che le richieste pull riflettano tale requisito.
• Incoraggia gli sviluppatori a tenere riunioni di progettazione / implementazione prima di toccare il codice per ridurre eventuali rilavorazioni identificate nelle Richieste pull.

Puoi dire di più sulla cultura della tua azienda in termini di team tecnici? Se stai lottando con l'idea che il codice sia pronto per la produzione quando uno sviluppatore vuole unirsi alla linea principale, allora cosa stai davvero dicendo ai tuoi sviluppatori? Stai dicendo loro che quando il loro lavoro è "finito", va bene se non funziona? Va bene se si rompe il sistema? Se stanno aggiungendo debito tecnico, forse va bene se possono giustificarlo e sono consapevoli di ciò che stanno facendo, e mostrano che possono tornare e fare il refactoring in seguito. Ma se sono ignari del perché stanno facendo qualcosa di pericoloso, quante volte lo lascerai passare?

Se hai uno sviluppatore junior, le loro prime richieste pull avranno ovviamente dei problemi. Alla fine dovrebbero prenderne il controllo. Se stai scoprendo che continuano ad avere problemi, potresti assegnare loro un lavoro per il quale non sono ancora pronti?

O forse hai bisogno di assumere un sostituto junior e licenziare quello che non è stato in grado di capirlo?

Sai cosa ho visto? Le persone che non sono sviluppatori competenti continuano a lavorare in un'azienda per anni solo a causa del nepotismo. Quindi, naturalmente, le loro richieste pull richiedono più revisioni. Nel linguaggio magro, sono "sprechi": un tiro sulla squadra e un tiro sulla linea di fondo.

Quindi devi decidere tu stesso: quante richieste pull ci vorranno perché i tuoi ragazzi mostrino competenza e hai il coraggio di lasciar andare quelli che non lo fanno?