Come gestire il codice "quasi buono" da uno sviluppatore junior? [chiuso]

Se pensi che il codice debba essere corretto prima di unire, scrivi commenti. Preferibilmente con "perché" in modo che lo sviluppatore possa imparare.

Tenere presente che il codice viene letto molto più spesso di quanto scritto. Quindi le cose che sembrano "minori" possono effettivamente essere veramente importanti (nomi di variabili per esempio).

Tuttavia, se ti trovi a fare commenti che sembrano noiosi, forse prendi in considerazione:

• Il tuo elemento di configurazione dovrebbe rilevarli?
• Hai una chiara "guida dello sviluppatore" per fare riferimento (o è tutto documentato nella tua testa)?
• Questi commenti contribuiscono effettivamente alla qualità del codice?

Molte persone sacrificano la produttività sull'altare del processo o della perfezione. Fai attenzione a non farlo.

Cerca di visitare il tuo collega di persona, se possibile. O usare le videochiamate. Costruire una relazione rende più facili da gestire le critiche (anche le revisioni del codice).

Se trovi che un pezzo di codice ha troppi problemi di back / forth, richiedi la revisione su parti di codice più piccole. È probabile che i cambiamenti incrementali evitino alcuni dei problemi di progettazione più significativi, perché sono per definizione più piccoli.

Ma assolutamente non unire le cose e poi tornare indietro e aggiustarlo. Questo è passivo e aggressivo e se lo sviluppatore ti trova a fare questo, ucciderai il loro morale.

Conserva le critiche sul codice piuttosto che sullo scrittore.

Ogni lavoro prodotto viene fornito con un attaccamento emotivo intrinseco. Prendi in considerazione l'eventualità di semplificare questo processo dissociando il codice dallo scrittore il più possibile. La qualità del codice dovrebbe essere stabilita in modo coerente come obiettivo reciproco che entrambi dovete affrontare, insieme, piuttosto che un punto di attrito tra voi.

Un modo per raggiungere questo obiettivo è scegliere saggiamente le tue parole. Anche se agli individui STEM piace pensare di essere altamente logici, le emozioni fanno parte della natura umana. La verbosità usata può essere la differenza tra sentimenti feriti o risparmiati. Dicendo "Questo nome di funzione sarebbe più coerente con le convenzioni se fosse in inglese" è preferibile a "Hai scritto questo nome di funzione in modo errato e dovrebbe essere in inglese." Mentre il secondo è ancora mansueto e da solo sembrerebbe giusto, rispetto al primo i suoi difetti diventano ovvi - quando si prepara cosa dire di persona o una e-mail esamina se il tuo contesto, le parole e il focus sono sul problemi piuttosto che la persona .

Lingua del corpo

Mentre le parole sono importanti, la maggior parte delle comunicazioni è non verbale. Presta attenzione al linguaggio del corpo, anche sottigliezze apparentemente insignificanti come l'orientamento mattter, ad es. Molte interazioni senior-junior si verificano faccia a faccia, tuttavia un approccio side-by-side sarebbe molto più favorevole al risultato desiderato.

Dai un feedback positivo e onesto

Una moltitudine di studi dimostrano che le informazioni vengono apprese più rapidamente e sono meglio conservate quando premiamo un buon comportamento piuttosto che punire quelli cattivi. A volte sottolineo che la performance è stata migliorata con un semplice "buon lavoro" o con uno più specifico "Ho notato recentemente che il tuo stile ha abbinato i nostri standard a un tee, ottimo lavoro!" anche integrando questo riconoscimento del miglioramento facendoli, a sua volta, consigliare qualcun altro sui problemi che hanno modificato può fare la differenza per il tuo dev junior e il suo lavoro.

The guy is open to criticism and willing to learn, but I got some doubts how much should I push some stuff.

Spingi tutto ciò che puoi. Se il ragazzo sta imparando, ed è il tuo lavoro rivedere il suo codice, entrambi avete molto da guadagnare se fa un buon lavoro.

Significherà un minor numero di codice da sottoporre a revisione in futuro e probabilmente darà al tuo team un obiettivo di assunzione.

Inoltre, se ti trattieni, non stai aiutando, ma condiscendente.

Proprio per il fatto che hai postato la tua domanda qui, chiedendo se stai facendo troppo, già mi accetti che non hai bisogno di questo consiglio specifico, ma per gli altri, eccolo: ricorda che spingendo strong non intendo essere un coglione.

Essere un mentore non è un compito facile. Dovrai anche dare un po 'di spazio per lui per fare alcuni errori e correggerli da solo, ma assicurati che lo farà da qualche parte che non infligge danni reali.

In base alla tua descrizione, vorrei lasciarlo a: "questo è bello, ci sono alcune cose che avrei fatto diversamente ma non sono molto importanti."

Come sembri capire, le critiche hanno un costo e se passi un sacco di tempo su dettagli insignificanti, diventa un problema morale. Idealmente tutti gli standard di codifica sono controllati automaticamente e non puoi costruire se non li stai seguendo. Questo è un enorme risparmio di tempo e consente di mettersi al lavoro. Se riservi le tue critiche per "le cose che contano", il tuo consiglio avrà un impatto molto maggiore e sarai considerato un mentore stimato. È davvero fondamentale distinguere tra cose che non sono buone e cose che non sono esattamente come faresti tu.

Credo nel concetto del momento teachable . Se lo sviluppatore ha abbastanza capacità mentali, potrebbe chiedere i dettagli su ciò che farebbe diversamente. (S) potrebbe non farlo e va bene. Le persone si bruciano e all'inizio di una carriera può richiedere molta energia mentale per realizzare cose che sembrano semplici in seguito.

Prenderei in considerazione l'idea di accettare il suo lavoro quando è accettabile, non perfetto. E poi il prossimo compito è dopo una discussione per rifattenerlo immediatamente facendo tutti i piccoli ma importanti cambiamenti che vuoi.

Quindi, quando il lavoro viene accettato per la prima volta, il tuo messaggio è che non era male, e alcuni luoghi lo avrebbero accettato come abbastanza buono - ma non i posti in cui vorresti essere come uno sviluppatore junior che vuole imparare il suo commerciare correttamente.

Quindi non dici "rifiuto il tuo lavoro perché non è abbastanza buono". Dici (a) "Accetto il tuo lavoro perché è abbastanza buono", e poi (b) "Ma lo voglio meglio".

Domanda abbastanza ampia, ma ecco un paio di idee.

1. Recensioni peer (dello sviluppatore junior)

   Il modo migliore per qualcuno di imparare il modo "giusto" è vedere gli altri farlo. Tutti i tuoi sviluppatori eseguono le revisioni del codice? Potrebbe non essere una cattiva idea lasciare che anche il tuo sviluppatore junior li esegua (anche se dovresti anche richiedere almeno una recensione da uno sviluppatore senior). In questo modo vedrà in azione i bravi programmatori, inoltre osserverà che ci sono commenti di revisione rivolti a ingegneri diversi da lui stesso, il che significa che non è personale.

2. Commenti precedenti / revisioni di attività

   Permetti allo sviluppatore di partecipare alla sua ripartizione dei compiti. Fagli registrare il progetto previsto nelle note delle attività e invia una "revisione del codice" senza alcun changeset e solo il compito. In questo modo puoi rivedere il suo piano prima che abbia scritto una singola riga di codice. Una volta che il suo compito è stato rivisto, può iniziare a programmare (dopo di che presenterà un'altra recensione del codice). Questo evita la situazione demoralizzante in cui lo sviluppatore ha scritto un sacco di cose e devi dirgli di riscriverlo.

Se il codice viola oggettivamente uno standard scritto e non ambiguo, allora penso che dovresti continuare a respingere fino a quando ogni problema non sarà risolto. Certo, potrebbe essere leggermente fastidioso per lo sviluppatore i primi commit, ma potrebbero anche imparare le linee guida prima più tardi che dopo.

Inoltre, se permetti alcune violazioni degli standard qua e là, imposteranno un precedente errato - vedi teoria delle finestre rotte . Inoltre, è molto più facile ricordare di seguire gli standard se è già applicato coerentemente al codebase. Quindi, davvero, vince tutti, compresi gli sviluppatori junior in questione.

Non penso che il morale sia un grosso problema finché lo standard di codifica è scritto. Solo se diventa più soggettivo "beh, I lo farebbe diversamente" -territorio, allora dovresti essere preoccupato, dal momento che l'approccio degli sviluppatori potrebbe essere altrettanto valido.

Considera l'adozione di un flusso di lavoro di revisione del codice, in cui gli sviluppatori postano i loro commit proposti su uno strumento come Github Pull Requests o Phabricator Diffusion e ottengono il peer sign-off prima di atterrare le loro modifiche sul ramo master condiviso.

In questo modo, piuttosto che criticare retroattivamente o chiedere a qualcuno di rifare ciò che è già stato fatto, il lavoro è solo non ancora fatto fino a quando non passa la peer review. Il back and and-end con i peer fa parte del processo di ingegneria del software tanto quanto il back-and-out con il compilatore.

Puoi pubblicare le tue preoccupazioni come commenti su linee particolari e avere discussioni su di esse. Lui può fare lo stesso con il tuo codice. La discussione rimane incentrata sulle specifiche modifiche del codice proposte, e non sulle prestazioni o sulle competenze di qualcuno in generale.

Anche i brillanti ingegneri senior della mia azienda sono grati quando le recensioni del codice catturano errori di battitura o li costringono a rendere le cose più chiare. È assolutamente normale che i nuovi assunti richiedano più turni di iterazione. Nel corso del tempo, inizierai a correggere riflessivamente i tipi di problemi che potresti attirare i commenti prima pubblicando una diff. Ottenere una percentuale più alta delle tue differenze accettate al primo tentativo è come sai che stai migliorando.

I'm not pushing back code constantly on what to a novice might seem like minor details, which can be quite frustrating, but I'm also worrying that being too 'soft' might prevent the guy from learning how to do some stuff.

Queste sono sia vere possibilità che preoccupazioni valide. Chiedi allo sviluppatore come si sente a riguardo.

Supponendo che tu abbia un flusso di lavoro per la richiesta di pull o la revisione del codice, e sembra che tu lo faccia, ti consiglio di notare le cose che sono "non critiche" o "preferite".

Se vedi un PR in uno stato simile a quello che stai descrivendo, con alcuni problemi stilistici minori o che necessitano di un refactoring non critico, lascia un commento, ma non esitare ad approvarlo. Dire qualcosa del tipo "In futuro, forse cercare di evitare nomi di metodi come questo in favore di qualcosa come descrittivoMethodName" documenta la tua opinione senza costringerli a cambiarla o bloccarne lo sviluppo.

Ora sanno quali sono le tue preferenze e, se stanno cercando di migliorare, si spera che notino una situazione del genere in futuro. Inoltre lascia la porta aperta a loro in realtà modificandolo in quel momento, se fossero d'accordo con te e lo vedessero come abbastanza critico.

I'm dealing with a junior developer who's working remotely from a coding factory.

Purtroppo non è una situazione ideale: un programmatore avanzato responsabile di un programmatore alle prime armi, con separazione geografica. Non sorprende che ci sia un po 'di tensione, ma la disparità può essere mitigata.

Sono curioso, cosa intendi per "fabbrica di codici"? Questa terminologia, per me, indica un atteggiamento problematico che potrebbe esacerbare alcuni dei problemi di gestione che hai menzionato.

… violation of SRP, God objects, non-meaningful names for methods or variables; I point out what he has to fix and try to explain why it is wrong.

Il problema, penso, è che il tuo sviluppatore junior stia sputando codice senza aver attraversato un processo di progettazione appropriato. Questo è un fallimento da parte tua, come manager e sviluppatore senior, per fornire indicazioni e insegnare buone abitudini di sviluppo del software. È possibile evitare che il codice errato venga scritto in primo luogo se si lavora prima insieme per tracciare un contorno. Sarebbe preferibile criticare e riscrivere il codice dopo che è stato prodotto, sia in termini di efficienza che di morale.

Probabilmente avrai bisogno di riadattare il tuo flusso di lavoro. Sembra che tu ti stia aspettando che lui ti fornisca dei prodotti. Ciò di cui hai bisogno è una collaborazione più stretta, in modo da poter fornire indicazioni in ogni fase dello sviluppo. Parla del design e dell'interfaccia prima che inizi la codifica. Mentre sta accadendo la codifica, fare checkpoint più frequenti, per individuare i problemi in precedenza. Se possibile, prova la programmazione della coppia, tramite condivisione dello schermo con un canale audio.

Tutto ciò richiederà un maggiore sforzo da parte tua, ma probabilmente ne valuterà la pena, considerando la relazione problematica che hai attualmente.

Se si tratta di una violazione degli standard di codifica, mostragli dove è così che lui / lei conosce. Se devi continuare a mostrargli lo stesso errore, potresti avere un problema con qualcuno che non è in grado di conformarsi alle regole o si rifiuta di farlo. Non usare il tuo tempo libero per correggere gli errori. Questa persona dovrebbe correggere i propri errori in modo che non li facciano più.

Dì loro sempre cosa hanno fatto bene e come possono migliorare la volta successiva. Possiamo sempre migliorare in alcune zone. Il feedback è fondamentale per diventare migliori a qualsiasi cosa.

Un'altra idea per affrontare "troppe critiche" è di fare di volta in volta un compito da te stesso e lasciare che lo sviluppatore junior faccia una revisione del codice per te. Questo ha almeno due vantaggi:

• possono imparare come dovrebbero essere fatte le cose.
• nei casi in cui esistono più soluzioni valide o nomi variabili accetto suggerimenti di approcci diversi ma (quasi?) ugualmente validi. Quando aggiusto il mio codice a causa del commento di qualcuno, sto mostrando alle persone che sono rispettate e che le critiche riguardano sempre solo il codice, indipendentemente da chi sia l'autore.