È la mia prima settimana di lavoro, ho controllato il codice e mi viene detto di guardarci intorno fino a quando non avrò un incarico la prossima settimana. Cosa faccio? [duplicare]

• Scopri come utilizzare il prodotto.
• In generale, la maggior parte delle applicazioni utilizza un database. Dai uno sguardo allo schema. Cerca di capire in che modo il codice utilizza i dati.

Se impari facendo (come me), direi di provare a trovare alcuni bug da correggere. Se riesci a rimanere bloccato in alcuni bug a bassa priorità, sarebbe un ottimo modo per acquisire familiarità con il codice.

Di solito inizio a curiosare nel sistema di tracciamento dei difetti: dai un'occhiata a dove la maggior parte dei difetti sembra essere centrata e inizia a guardare quel codice; le probabilità sono che lavorerai presto su quella roba comunque, quindi è un buon punto di partenza.

In caso contrario, puoi sempre chiedere a qualcuno una "visita guidata" dell'architettura del progetto e poi esaminare le aree che ti interessano o menzionano che sono problematiche. Per lo meno avrai un'idea di come sono messe insieme le cose.

Se il tuo datore di lavoro (o tu) paga per qualcosa che può generare diagrammi dal codice, ne creerei alcuni basati sulle prime due sezioni e ottieni una panoramica grafica- potrebbe aiutarti a ottenere un quadro migliore di come le cose interagiscono .

Prima di tutto, raccogli alcune conoscenze di dominio. Cosa dovrebbe fare il codice e così.

Quindi, in nessun ordine particolare

• fai clic su un debugger.
• passare attraverso le suite di test (se ce ne sono)
• leggi la documentazione su di esso (se presente esiste qualsiasi)
• leggi la documentazione / cerca eventuali librerie di terze parti utilizzate
• interagire con i membri del tuo team (questo è ciò che chiamiamo KT - trasferimento di conoscenza)

A meno che non siano completamente irragionevoli, non si aspettano che tu colpisca il terreno come esperto la prossima settimana.

Detto questo, più puoi imparare, più puoi impressionarli. Sempre buono per impressionare il supervisore.

Se impari facendo, impari come faccio io, così posso offrire alcune raccomandazioni. Presumo che tu abbia una versione compilata del codice. Prendi confidenza con il modo in cui funziona l'applicazione, le stranezze, tutto ciò che pensi "huh, non so come lo farei", tutte le parti che potrebbero essere interessanti sotto il cofano. Inizia lì nel codice.

Quindi, se vuoi davvero impararlo, inizia a seguire il flusso di dati / controllo attraverso l'applicazione. Inizia da una posizione interessante o direttamente all'inizio dell'interazione dell'utente e osserva come i dati passano attraverso il sistema. Scopri cosa succede a un livello basso con qualsiasi interazione dell'utente o attività basate sul tempo. Dai un'occhiata e vedi se ci sono dei punti che ritieni di poter ottimizzare o migliorare, studia quei punti (e se puoi, modificali e compilarli. Non spingere ancora una modifica alla gestione se questa è una grande applicazione, ma tieni un elenco interno delle cose che puoi far emergere mentre entri più in azienda, provare a spingere un cambiamento in un sistema che non comprendi completamente può avere molti effetti collaterali inaspettati, quindi aspetta di capire completamente il sistema .)

Tuttavia, la cosa migliore è che la cosa migliore che puoi concentrarti sull'apprendimento veloce in una nuova azienda sono le regole aziendali. Se c'è un settore centrale in cui lavorerai, impara . Se ce ne sono alcuni, imparali tutti. Se è più di un contratto a contrattare affari, questo sarà meno applicabile.

Chiunque può codificare. Ma se capisci cosa fa il codice che stai scrivendo e lo spieghi in termini commerciali espliciti, vinci.

Ecco il mio elenco di cose da trovare:

• Costruisci un modello mentale del codice. Quali sono le classi principali? Come si presenta la gerarchia di classi?
• Convenzioni. Come vengono chiamate le variabili? Dove sono i test nel codice? C'è un modello su come è strutturato il codice di un file, ad es. membri in cima e metodi sottostanti?
• Se c'è una lista di bug o una lista di funzionalità in giro per cose da fare, prendine un paio e prova a fare quelle attività. Certo, potresti non essere veloce come qualcun altro, ma questo farà qualcosa che ti porterà nel codice con uno scopo. I bug a bassa priorità possono essere un esempio di piccole cose che sono semplici da fare, lasciate da altri come cose più importanti potrebbero essere fatte ma potrebbe essere utile mostrare che non hai paura di rimboccarti le maniche e tuffarti proprio dentro Portare a termine qualcosa. Anche se il bug è stato risolto da qualcun altro, guarda le conoscenze acquisite sul codice nel processo.
• Guarda i tuoi collaboratori per i pattern nelle interazioni. Chi sono le persone che sembrano più loquaci? Chi sono quelli che sembrano essere gli esperti di codifica? Chi ha quale ruolo? Questo è qualcosa che si può ottenere se si presta attenzione e si collegano i punti. Anche questo non è necessariamente facile, ma potresti considerare l'osservazione di qualcuno per un'altra possibilità qui. "Lascia che segua Bob per alcuni giorni e faccia come lui", tipo di pensiero che può o non può andare oltre. Com'è qui il processo?

Consiglierei di non andare e "navigare" in rete durante questo periodo.

Guarda intorno alla base del codice, giocaci e cerca di eseguirla (se possibile), se non puoi eseguirla, prova a capire che cos'è il codice e cosa fa. Se trovi il codice che ti interessa o ti imbarazza, cerca di trovare la documentazione o semplicemente chiedi a qualcuno.

Non aver paura di porre domande agli altri, possibili quelli che hanno sviluppato l'applicazione. Saranno i tuoi colleghi e sapranno che sei nuovo, quindi sono certo che sarebbero lieti di aiutarti.

Prima imparerai questa roba, prima riuscirai a "imparare facendo" invece di limitarti a cercare il codice. :)

Riepilogo:

• Non limitarti a navigare in rete:)
• Non aver paura di porre domande
• Scopri documentazione, schema, gioca (se possibile) con l'applicazione
• Quanto prima finisci la fase di apprendimento iniziale, prima puoi iniziare il passaggio "facendo"

Questo potrebbe sembrare breve e non pensato, ma è quello che uno dei miei colleghi mi ha detto di fare quando mi è stata concessa una settimana per occuparmi della mia base di codice prima che iniziassi davvero:

Apri la soluzione, compila, eseguila e F11 (passa alla riga successiva nel debugger di Visual Studio 2010), finché non ti sanguinano gli occhi.

Ecco alcuni passaggi che ti consiglierò di fare.

1. Se hai della documentazione, inizia a leggerla e testala applicandola sul tuo codice

2. Hai bisogno di vedere come framework / codice hai, funziona, non è importante sapere in realtà come il framework sta facendo qualcosa, ma questo passo è farti un'idea di cosa può fare usando l'API già presente / funzioni e come è possibile inserire nuovi codici / moduli come le cose al suo interno.

3. Quindi devi provare a fare quanto più pratica delle cose presenti in esso, ma con un approccio di apertura mentale. L'approccio di mentalità aperta significa che lo farai per capire veramente lo scopo, non solo per portare a termine il lavoro.

4. Una volta eseguito il passaggio 3, avrai più lavoro svolto e in questa fase se avrai tempo allora sarà il momento giusto per verificare quanto internamente quel codice o framework presenti funzioni perché durante il lavoro è possibile che sia necessario modificare alcune cose o correggere alcuni bug presenti in quel framework già presente.

Dopo averlo fatto, sarai quasi pronto per il lavoro.

Avvita il codice .. Leggi leggi i documenti! oh .. aspetta ...

Penso che la cosa migliore da fare fosse provare a familiarizzare con il codice. Eseguilo, leggilo, capisci il flusso del programma, capisci cosa fa ogni parte del codice, ecc. In questo modo quando hai il tuo incarico, avrai una comprensione del codice e dovresti avere un'idea molto migliore di come fare ciò che vogliono che tu faccia.

Inoltre, non può far male chiedere se c'è qualcosa in particolare su cui dovresti concentrarti mentre lo guardi. Loro (essendo il tuo lead o manager) potrebbero non avere ancora un compito specifico, ma potrebbero avere un'idea ed essere in grado di darti un po 'di attenzione.