Le richieste pull sono il posto per gli juniores di formazione

No. Le richieste di pull non sono il posto per l'allenamento. 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 mi sia sfuggito qualcosa, dopo tutto sono umano." E sospetto che sia esattamente ciò che sta facendo il tuo apprendista. Pensano onestamente che sia bello andare.

Ecco un'idea estrema (gioco di parole). Abbina il programma con l'apprendista che ti sta dando il bruciore di stomaco. Come membro di un gruppo più anziano, è compito tuo 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 di pull, allora dovrebbe essere sicuramente risolto lì. 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 occorrono diverse iterazioni di revisione del codice per risolvere un difetto di progettazione fondamentale o un problema su larga scala, allora ci sarà una strong tentazione di trascurare i problemi minori menzionati sopra, a causa di scadenze o esaurimento generale con la recensione. Idealmente, il team sarebbe abbastanza elastico da resistere a questa tentazione, ma probabilmente è meglio non creare una situazione che porterebbe ad esso.
2. Ricevere una revisione del codice con un gran numero di commenti non è una grande esperienza per uno sviluppatore di noleggio junior / nuovo. Sì, rispondere al feedback è un'abilità che dovranno sviluppare, ma è anche vero che gli sviluppatori non sono sempre abili nel rispondere con tatto al codice che non gli piace.

Coppia di recensioni di programmazione e design sono luoghi preferibili per un feedback su larga scala.

Detto questo, sarebbe ancora peggio lasciar passare il codice per paura che affrontarlo durante le revisioni del codice sia "sbagliato" e potrebbero esserci alcune circostanze (ad esempio team remoti) in cui questo è il meglio che puoi fare. In tal caso, risolvi i problemi nella revisione del codice e affronta anche i problemi nel tuo processo di sviluppo che ha ottenuto fino a questo punto.

Sebbene la ricerca del problema durante una richiesta di pull potrebbe non essere l'ideale, è sicuramente meglio che in testing o in un problema di produzione.

Lo esprimerei più come le richieste di pull non dovrebbero essere il solo posto dove addestrare le persone. Inoltre, gli sviluppatori junior non sono gli unici che potrebbero aver bisogno di un addestramento in una richiesta di 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.

C'è un costo molto piccolo per mantenere aperta una richiesta di pull per un po '. Dagli il maggior numero di feedback che vuoi, da quante più persone vuoi, lascialo in pace fino a quando gli autori non ti notificheranno che pensano che sia pronto per la fusione. Una richiesta pull è un ottimo strumento centrale per comunicare le modifiche al codice proposte, sia che siano completamente pronte o che necessitino di molto lavoro.

Alcune recensioni di richieste pull risultano poco più di un timbro di gomma e alcune di quelle inviate in esterno a una squadra potrebbero richiedere un mese di andata e ritorno. Il primo tipo è bello quando riesci a ottenerlo, ma ciò non significa che il secondo tipo non sia prezioso. Cercare di convincere le persone a presentare richieste di pull perfette per tutto il tempo sarà frustrante per tutti.

Ho sempre pensato che uno dei tratti distintivi di una buona guida sia qualcuno che fornisce la formazione aggiuntiva necessaria durante ogni ciclo di sviluppo. Per me, questo significa che non sto solo programmando me stesso, o rivedendo il codice, ma seduto con altri sviluppatori junior, ho programmato una coppia con loro per aiutarli a evitare il tipo di mine che ho scavalcato.

Principalmente, non ho illusioni sul fatto 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 un codice di qualità al cliente. Preferibilmente in tempo, sul budget, facendo ciò che vogliono. Riconosco, tuttavia, che è impossibile per me portare a termine tutto il lavoro da solo, quindi è incombente su di me come un vantaggio per aiutare tutti ad aiutare il team ad avere successo. E questo significa riconoscere le opportunità di allenamento quando appaiono in natura.

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

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

Se utilizzi feature e release branch in una strategia di branching in stile gitflow, le tue richieste di pull diventano qualcosa di più dei candidati al rilascio. Non pronto per la produzione, ma qualcosa di più approssimativo. Conoscendo il codice compilato (a destra) e disponi di un numero sufficiente di test per presentare una dichiarazione decente in grado di soddisfare gli obiettivi della storia utente. E dal momento che hai già eseguito diversi test di integrazione nel tuo ambiente di sviluppo, hai una grande demo pronta per l'uso 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 che l'assistenza non riguarda la codifica generale. Invece, è 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 conoscenza di ogni cambiamento che hanno incluso nel PR. E anche allora, anche dopo averli soppesati con test unitari, demo e un sacco di domande, non c'è ancora alcuna aspettativa che le modifiche proposte siano pronte per la produzione.

Il codice è vicino dopo tutto questo. Ma poi lasciamo che il QA lo torturi.

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

Questa è la mia risposta dopo il feedback dato e la mia comprensione ora in base alle risposte e ai commenti ricevuti. Grazie a tutti.

Riepilogo

• Non aspettarti o far rispettare le richieste di pull perfette del pipistrello in quanto ciò diventerà solo frustrante per tutti i soggetti coinvolti.
• Ma continua a renderlo il nostro obiettivo per le richieste di pull perfette.
• Aspettati alcuni quantità di collaborazione / assistenza nelle richieste pull. Dopotutto, questo è ciò che stai essenzialmente richiedendo creando una richiesta di pull.
• Se aumenta un po 'a causa di difetti di progettazione o difetti di implementazione, passa del tempo con quello sviluppatore e fa un paio di programmazione per costruirli e ottenere il loro codice più vicino all'obiettivo . Questo è il ruolo di tutti gli sviluppatori senior.
• I ragazzi avranno bisogno di più sessioni di programmazione coppia rispetto agli sviluppatori intermedi. Quindi aspettati che le richieste di pull riflettano questo requisito.
• Incoraggiare gli sviluppatori a organizzare riunioni di progettazione / implementazione prima di toccare il codice per ridurre eventuali rilavorazioni identificate in 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 dicendo veramente ai tuoi sviluppatori? Stai dicendo loro che quando il loro lavoro è "finito", va bene se non funziona? Va bene se rompe il sistema? Se stanno aggiungendo il debito tecnico, forse va bene se riescono a giustificarlo e sono consapevoli di quello che stanno facendo, e mostrano che possono tornare indietro e fare il refactoring più tardi. Ma se sono ignari del perché stanno facendo qualcosa di pericoloso, quante volte hai intenzione di lasciarlo passare?

Se hai uno sviluppatore junior, le prime richieste di pull avranno ovviamente dei problemi. Alla fine dovrebbero prendere il controllo. Se stai riscontrando che continuano a riscontrare problemi, potresti assegnare loro lavori per i quali 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 per il nepotismo. Quindi, ovviamente, le loro richieste di pull richiedono più recensioni. Nel gergo Lean, sono "sprecati": un trascinamento nella squadra e un trascinamento nella linea di fondo.

Quindi devi decidere tu stesso: quante richieste di tiro ci vorranno per dimostrare ai tuoi juniores la competenza, e hai il coraggio di lasciar andare quelli che non lo fanno?