Ecco le tecniche che utilizzo per il nostro ambiente e potrebbero funzionare per la tua:
- Accoppia programma / codice live nell'area di conoscenza / codice che stai trasferendo se è per un individuo o forse un piccolo gruppo
- Prepara un diagramma valido dell'architettura del codice base e aggiorna la documentazione architettonica che hai attualmente
- Avere una panoramica del layout tecnico delle applicazioni memorizzato o prontamente disponibile in modo che tu possa percorrere l'intera intesa con una lavagna in un'ora
- Conoscere e documentare maggiormente le aree problematiche. Queste sono le parti difficili del codice con cui hai lottato (e potrebbe ancora avere difficoltà) che ora anche altri avranno problemi
- Prepara una wiki in cui puoi avere a portata di mano documentazione leggera e qualsiasi informazione in modo da avere a portata di mano un repository vivibile di informazioni per i nuovi sviluppatori
- Ripassa tutto il codice e le aree del codice di base che probabilmente hai dimenticato (qualcosa di 3 mesi forse?)
- Sii paziente quando spieghi il codice!
Queste sono solo alcune delle idee che ho usato. Quello che penso davvero aiuta di più è essere in grado di pensare attraverso una presentazione della lavagna che puoi condensare in un'ora. La ragione per cui dico questo è che ti costringe a conoscere i pezzi più grandi del codice / architettura e quasi automaticamente evidenzierà alcune delle aree difficili da comprendere. Una volta preparato, diventa il punto di partenza per le discussioni sul trasferimento delle conoscenze iniziali con i nuovi sviluppatori. Avrai bisogno di questo come punto di partenza.
Da lì puoi entrare nei gustosi frammenti del codice e incarnare quelle discussioni di area. Ad esempio disponiamo di un'area di codice di replica dei dati complessa tra gli ERP e questo può essere difficile da comprendere, quindi abbiamo una serie di presentazioni e discussioni pronte per essere discusse con i nuovi sviluppatori. Sia le informazioni autodirette che le presentazioni dal vivo dettagliate.
Alla fine non c'è niente di meglio che stare seduti con lo sviluppatore e lavorare con loro nelle aree difficili. Le aree difficili saranno diverse a seconda dello sviluppatore con cui lavori, quindi questa codifica dal vivo e il passaggio a piedi spesso mettono in evidenza quelle aree mentre lo fai e ti permettono di adattarle al volo.
Il codice è di per sé la migliore documentazione se sei stato chiaro e coerente nel seguire un buon standard. Con una documentazione adeguata e una leggera spinta verso le aree giuste nella base di codice, gli sviluppatori più bravi capiranno cosa stavi facendo o stavi tentando di fare e formulare le loro domande a cui rispondere. È qui che approfondire gli aspetti fondamentali dell'architettura e del codice ti aiuterà anche a essere più preparato.
Alla fine goditi il processo e divertiti e sii paziente. La pazienza è la chiave. Insieme alla pazienza dovresti far sapere al tuo management che dovranno avere pazienza. Il trasferimento delle conoscenze richiede un po 'di tempo e nel tuo caso più di quello in cui sei stato l'unico sviluppatore dell'applicazione per anni. C'è molta conoscenza da condividere, quindi assicurati che sappiano che questo non è un lavoro da un giorno all'altro o anche solo per un mese.