Come introdurre il codice per un collega

11

Come procedi con l'introduzione della base di codice, che potrebbe essere piuttosto complessa e intricata con un sacco di "trucchi" per un nuovo membro della tua squadra?

Penso che il modo più semplice sarebbe avere l'architettura complessiva strutturata con diagrammi e impiegare un paio di settimane (o mesi) a dare alla nuova persona compiti ben definiti (e ben definiti) man mano che si abitua al codice.

Tuttavia, in qualità di consulente (e impiegato junior, a tale scopo), non posso sempre farlo a causa di limiti di tempo o designazioni di ruolo del team. (Sono stato su questo particolare progetto due volte più di chiunque altro, quindi "junior" non è in alcun modo "conosce meno il codice / progetto.")

Sono stato incaricato diverse volte di introdurre un nuovo membro nel progetto e nel codice, e purtroppo ogni volta trovo che non sono molto più bravo di quello precedente. Adoro diagrammi e immagini, ma spesso ritengo che non rappresentino adeguatamente la complessità di un sistema. (Che dire di tutti i "trucchi" del piccolo?)

Il progetto sta arrivando al punto in cui lo consegneremo al cliente, e per rendere le cose più difficili, la persona con cui farò un trasferimento di conoscenze è essenzialmente appena uscita dall'università. (Non che io sia molto più bravo quando faccio trasferimenti di conoscenze con gli sviluppatori senior.)

Frequento un gruppo di utenti una volta al mese e altre opportunità man mano che si presentano, quindi non sono inutilizzato per essere introdotto a nuovi argomenti, ma sento la mia capacità di replicare un'efficace condivisione delle conoscenze dolorosamente inadeguata.

Qualsiasi consiglio sarebbe molto apprezzato. Sto cercando soprattutto una linea guida che posso seguire. Ad esempio: dove inizi? Come procedi? Come si coprono tecnologie o modelli sconosciuti da parte dell'ascoltatore senza occupare tutto il giorno? Dove leghi la logica aziendale e la struttura del codice?

Grazie!

(Come sempre, non esitare a modificare la domanda come ritieni opportuno.)

    
posta emragins 13.08.2012 - 23:33
fonte

4 risposte

9

Il primo passo è ovviamente quello di rimuovere i "trucchi" dal codice. Un codice chiaro, conciso e coerente è più facile da ottenere, utilizzare e eseguire il debug.

Where do you start?

Chiedo al nuovo arrivato come vogliono entrare nel codice base. Tutti imparano diversamente. Ad alcune persone piace avere piccoli compiti con cui lavorare. Ad alcuni piace eseguire il debug del codice esistente. Alcuni vogliono vedere il codice in esecuzione per capire cosa fa. Alcuni vogliono iniziare dal punto di accesso e spostarsi. Alcuni vogliono i diagrammi visio ... Nessun modello impostato funzionerà meglio per tutti.

How do you cover unfamiliar technologies or patterns on the listener's part without taking all day?

Li evito. Lascia che siano scatole nere fino a quando il nuovo arrivato non chiede di loro. Quindi fornisci solo le informazioni sufficienti per ottenerne il significato, con il suggerimento di poterne imparare di più nel loro tempo libero, o chiedere in un secondo momento quando le informazioni generali sono più note.

Where do you tie in business logic vs. code-structure?

Cerco di non farlo. È quasi sempre meglio che il nuovo arrivato impari da solo, in modo tale che risieda nella loro mente in una struttura più naturale al loro modo di pensare.


Una cosa da ricordare è mantenere l'istruzione breve. Le persone tendono a fare check out abbastanza velocemente, quindi qualsiasi altra istruzione a quel punto semplicemente non "attacca". Mostra loro le cose per 15-60 minuti (persone diverse hanno un'attenzione diversa) poi prendi una pausa di 5-30 minuti per elaborarle.

    
risposta data 14.08.2012 - 01:08
fonte
2

Nella mia esperienza, un buon modo per colmare il divario tra l'ampia panoramica fornita da un diagramma di architettura e i dettagli grintosi di lavorare effettivamente con il codice è fare un drill-down del sistema, cioè cosa succede quando arriva una richiesta ( per codice server) o un utente fa un input (per codice client), quindi passo dopo passo spiega tutti gli strati di codice che sono coinvolti.

Un altro modo è un "tour guidato" del codice sorgente, cioè passa attraverso i pacchetti / namespaces / modules / directories e spiega in generale il codice in ciascuno di essi. Ovviamente ciò richiede che il codice sia presentato in modo un po 'logico.

    
risposta data 14.08.2012 - 00:39
fonte
1

Non stai insegnando loro la base di codice, stai insegnando loro il tuo lavoro tuo . Non cercare di pensare a ciò di cui potrebbero aver bisogno, guarda cosa hai effettivamente bisogno di sapere quando fai il tuo lavoro.

Scopri gli ultimi mesi di cronologia dei bug tracker, storie utente di Scrum, rapporti sullo stato e commit del controllo del codice sorgente. Quali file hai toccato di più? Qual è il codice più problematico? Quali compiti ti ha portato più tempo? È probabile che, se non l'hai toccato negli ultimi mesi, non è così importante come potresti pensare che sia.

Guarda la pila di stampe sulla tua scrivania. Controlla la tua recente cronologia del browser. Cerca le e-mail salvate a cui fai spesso riferimento, i contatti che utilizzi, i documenti che hai scaricato. Alcuni dei riferimenti più utili che ho trasmesso agli altri sono le note che ho tenuto per me quando ho iniziato a studiare o progettare il sistema. Quale materiale di riferimento è più utile per tu ?

Quindi tira fuori il tuo backlog noto. Di quali cose avresti bisogno per la ricerca al fine di completare quelle attività? Quali aree di codice contengono molto probabilmente il problema? Trasmetti queste informazioni come se stessi prendendo appunti per te.

Se fai riferimento a grafici o diagrammi nel tuo lavoro quotidiano, includi quelli. Se non ti sei mai preoccupato di crearne uno, probabilmente non sarà così utile neanche per il tuo successore / collega.

Uno dei compiti più difficili quando l'insegnamento sta cercando di mettersi nei loro panni. In questo caso, sei nei loro panni. Sfrutta al massimo.

    
risposta data 14.08.2012 - 06:02
fonte
0

Il lavoro di supporto è il migliore, prendi un bug facile e cammina attraverso le aree in cui verrà trovato. impareranno rapidamente come si combina il codice. Naturalmente, verranno a chiedere informazioni su questo bug e sulla base di codice, ma ci arriveranno (e verrà risolto un bug). Spesso è molto più facile capire le cose con gli esempi, allo stesso modo, è più facile elaborare una base di codice eseguendola attraverso un debugger.

Se non sei sicuro delle modifiche al codice (o lo sono, in genere non sarei sicuro delle correzioni del mio codice fino a quando non avrò familiarità con il codebase), puoi rivederlo prima del check-in.

Naturalmente, le tue idee attuali su panoramiche generali e schemi a blocchi sono i primi passi fondamentali.

    
risposta data 13.08.2012 - 23:58
fonte

Leggi altre domande sui tag