Come posso aiutare i membri junior a guadagnare la fiducia nella loro capacità di codice refactoring?

Question

Volevo vedere quello che la gente pensava fosse il modo migliore per aiutare i giovani membri ad acquisire fiducia nella loro capacità di codice refactoring. Trovo che spesso gli sviluppatori junior seguono semplicemente gli schemi esistenti e percepiscono un'avversione per rompere qualsiasi cosa a causa del rischio percepito. Sto cercando di convincerli a esaminare i requisiti (nuovi ed esistenti) e ad avere la mappa del codice sul modello di dominio rispetto a "modificare" o "piegare" il codice esistente per supportare nuove funzionalità. Volevo solo vedere se c'erano persone che hanno successo qui. Attualmente stiamo pensando di spingere più programmazione di coppia, TDD, revisioni di codice ecc., Ma volevamo verificare se ci fossero altre storie di successo ...

Answer 1

L'unica risposta affidabile sarà unit test IMHO. Non necessariamente TDD - basta che li faccia scrivere test per i metodi/classi esistenti che vogliono refactoring, assicurarsi che stiano facendo quello che stanno facendo, quindi permettere loro di refactoring come un matto affidandosi ai test per assicurarsi che il i metodi sono ancora validi.

Il livello di confidenza e le prove dell'unità di flessibilità consentono un immenso valore in questo tipo di attività.

Answer 2

Ti consiglio di avere Test unità prima di iniziare un pesante refactoring, se hai una buona copertura del codice, semplicemente eseguendo i test sarai in grado di vedere se qualche test fallisce, quale refactoring ha influenzato il comportamento del programma desiderato.

Fondamentalmente, il collaudo delle unità può darti la sicurezza necessaria al tuo refactoring.

Answer 3

Accetto: test delle unità e programmazione della coppia.

Answer 4

Il primo passo sarebbe quello di farli scrivere test per qualsiasi cosa vogliano refactoring FIRST e quindi refactoring. Penso anche che ci sia un certo merito nelle revisioni del codice con sviluppatori più esperti e nella programmazione di coppie.

Answer 5

Sembra che la programmazione di coppie con uno sviluppatore senior in combinazione con i test di scrittura sia la situazione ottimale. Se lo sviluppatore più esperto nella coppia è in testa, i test saranno solo parte di esso.

I test di scrittura lasciano margini di miglioramento. Scrivere i test in un ambiente di coppia è il migliore dei due mondi e quindi dovrebbe aumentare la fiducia più rapidamente.

Answer 6

Il mio suggerimento sarebbe quello di adottare un sistema che cambierà un po 'nel tempo e consentire a uno sviluppatore junior di fornire un piano su quali basi si desidera applicare ad esso, ad es. mancano i test unitari, quale schema di progettazione può avere senso utilizzare per aggiungere la nuova funzionalità, ritieni che questo sia un codice "buono" e in caso contrario, quali modifiche potresti apportare? Parte di questo è farli entrare nel codice e sentirsi a proprio agio con esso come quando uno sviluppatore non sa cosa fa qualcosa all'interno del sistema, è probabile che vogliano apportare modifiche minime per paura di rompere qualcosa e il successivo abbandono negativo. Se può esserci un membro anziano che può fungere da mentore e guidare ciò che gli sviluppatori junior suggeriscono in qualcosa che corrisponde meglio a ciò che si cerca, questa potrebbe essere la cosa più importante per entrare lì.

Si noti che per quanto sopra questo membro anziano può avere una buona dose di familiarità e in un modo già fatto la pianificazione di come apportare le modifiche che lo sviluppatore junior farà, ma l'idea è di ottenere i juniores più nel codice è come lo vedrei. Se gli sviluppatori più giovani possono prendere l'abitudine di saltare nelle cose ed essere incoraggiati a farlo, allora posso vedere un certo successo lì. La chiave è avere l'idea di come correggere ciò che lo sviluppatore junior suggerisce e tuttavia incoraggiarli a dare di più nel processo complessivo piuttosto che essere detto cosa fare.

Alcune persone hanno maggiori probabilità di emergere e di prendere una possibilità, la chiave è per il gruppo di vedere come questo si rivela come quello che vuoi alla fine è un gruppo di sviluppatori junior che lavorano su varie soluzioni in cui il senior lo sviluppatore potrebbe aver originariamente costruito il sistema o integrato diversi prodotti insieme e quindi può dare un input su ciò che dovrebbe essere fatto, ma agire da guida piuttosto che da un genitore nel fare le cose.

Un altro modo per visualizzare questo è semplicemente visualizzare le cose dal punto di vista dello sviluppatore minore. Se suggeriscono qualcosa e ottengono qualcosa, ad es. elogi o incarichi migliori, quindi questo può far rotolare le cose, anche se bisogna stare attenti a ciò che viene dato per continuare a tenere le cose su una tacca può incorrere in problemi se cresce troppo alto.

Answer 7

Non importa cosa, dovresti spingere per "programmazione di coppie in più, TDD, recensioni di codice ecc.". Dovresti anche assicurarti che i tuoi programmatori (Junior in anni e in abitudini) siano esperti nei fondamenti.

mi raccomando suggerendo che leggono di McConnell codice completo e di Fowler Refactoring.

Answer 8

• chiedere loro di scrivere o di indagare sui casi di test esistente
• Eseguire i quei casi di test, registrare il risultato
• Chiedete loro di refactoring del codice
• revisione del codice refactoring
• Eseguire i casi di test corrisponde alle osservazioni precedenti

Answer 9

Inoltre, provare a fare alcuni dojo di codifica. Una coppia si siede e programma al proiettore, ruotando uno sviluppatore ogni cinque minuti. Invitali a parlare del loro refactoring e del perché.

See: http://www.codingdojo.org/

Answer 10

Credo che la questione non è specifico per C#, quindi mi suggerire di dare una prova con Java utilizzando Eclipse. Eclipse ha i migliori strumenti di refactoring che abbia mai visto finora (anche se non ho mai provato IntelliJ IDEA o Resharper). Ho beneficiato molto imparando il refactoring tramite Eclipse, specialmente usando la finestra di anteprima prima di eseguire qualsiasi modifica.

Answer 11

Vorrei raccomandare una combinazione di libri, strumenti, codifica e tutoraggio.

Prima di ogni altra cosa - chiedere al candidato di acquistare o prendere in prestito il Refactoring di Martin Fowler e leggerlo.

Se si dispone di un buon sistema di controllo sorgente, dovrebbe essere banale creare un ramo separato con cui giocare. Inoltre, se il risultato finale dell'esercizio è utile, puoi facilmente inserirlo nel bagagliaio.

Successivamente, selezionare un'attività specifica che si ritiene richieda loro di comprendere la struttura dell'applicazione. Ad esempio, chiedi loro di strumentare una parte del sistema. Questo fornisce un compito all'interno del quale lavorare invece di direttive generali (come leggere la documentazione del framework o leggere questo codice)

La parte successiva è chiedere che i test vengano scritti per supportare la funzionalità toccata da questa attività. Esaminare i test e incoraggiare la scrittura di test completi. È importante utilizzare uno strumento per questo come NUnit o se il tuo IDE supporta il test delle unità, usa quello. Incoraggia la persona a fare domande e scoprire perché le cose sono come sono.

Se si utilizza un IDE che lo supporta, introdurre gli strumenti di refactoring nell'IDE e incoraggiarli a rifattorizzare il codice. Utilizzare la programmazione di coppie o revisioni periodiche del codice per guidare la persona. I test possono essere utilizzati per mostrare come i test unitari sono una parte vitale di un buon sforzo di refactoring. Inizia in piccolo - potrebbe cambiare il nome delle cose o estrarre i campi in proprietà e poi passare a quelli più complessi.

Speriamo che, entro la fine dell'esercizio, non solo la persona essere abbastanza comodo a mettere in discussione, modificare e modificare l'applicazione e si dovrebbe avere alcune funzionalità utile fuori di esso pure :-)