Sono appena entrato in una nuova azienda e ho iniziato a studiare uno dei loro sistemi più grandi. Per essere produttivo, ho bisogno di capire l'intero sistema senza troppi aiuti. Altri programmatori sono molto impegnati e non ho tempo per tenere le mani.
Usavo la mappa del cervello per disegnare una rappresentazione pittorica del sistema. Qualche consiglio su quale sia il giusto appproach per analizzare un grande programma? A proposito, è un .net prgoram.
Vorrei iniziare con la documentazione del sistema: documento di progettazione, documento (i) dei requisiti, schema del database o eventualmente un manuale dell'utente. Se sei fortunato, troverai tutto questo, ma trova tutto ciò che puoi. Leggi questi per avere un'idea di cosa dovrebbe fare il sistema. Poi giocherei con il sistema in un ambiente di test per avere un'idea di come funziona. Una volta che mi sento a mio agio con ciò che il sistema dovrebbe fare, inizierei a guardare il codice per il sottosistema più semplice che riesca a trovare. Forse un singolo modulo di inserimento dati o un singolo algoritmo di analisi, la chiave è trovare qualcosa di abbastanza piccolo da poter capire completamente quel codice. Continua a ripetere fino a quando non hai conquistato l'intero sistema.
Se questo è un sistema di qualsiasi complessità, ci vorrà molto tempo. Vorrei anche verificare con il tuo nuovo manager per vedere quali aree (s) vuole che ti concentri. La cosa più importante è attaccare questo problema in blocchi gestibili, non puoi imparare tutto in un colpo solo.
For me to be productive, I need to understand the entire system without too much help. Other programers are really busy and dont' have time to hold my hands.
Dovresti prendere questo è un segno di pericolo. Potresti voler cercare pascoli più verdi.
Dovrebbe esserci una grande presentazione del sistema nel suo insieme. Molteplici visualizzazioni di immagini così grandi. Un fumetto per la gestione, uno più dettagliato per l'architetto di sistema, una vista diversa per l'integratore di sistema. Avrebbero dovuto mostrarti quelle immagini il primo giorno e ti hanno guidato attraverso di essa. Qualcuno dovrebbe farti da guida, indicandoti materiali di formazione, esercitazioni e documentazione; mostrandoti le risorse online; controllando i tuoi progressi; ed essere disponibile ora e poi per rispondere alle domande che hai. Non dovresti aspettarti che il mentore trascorra tutto il suo tempo con te, ma quel mentore dovrebbe essere lì.
Con un sistema di grandi dimensioni, potrebbero essere necessari mesi, a volte diversi mesi, per consentirvi di essere subito operativi e diventare una risorsa produttiva per l'organizzazione, e questo è con un sistema appropriato. Senza un sistema adeguato, le probabilità sono buone che nessuno capisca il sistema nel suo insieme. I programmatori sono troppo occupati perché sono impegnati a creare un caos contorto che alla fine arriverà a crollare su di loro.
Personalmente, mi piace scavare e iniziare a cambiare le cose (impara facendo). Chiedi un compito e scopri come ottenere quel compito all'interno del sistema. Non aver paura di fare domande - le uniche domande stupide sono quelle a cui sai già la risposta. Se riesci a ottenerlo, chiedi una revisione del codice prima di controllare qualsiasi cosa nel repository (qualsiasi azienda decente dovrebbe farlo comunque con i nuovi utenti).
Non imparerai a conoscere l'intero sistema, ma una volta che avrai familiarizzato con il cambiamento di piccole parti del sistema, troverai più facile espandersi in altre aree e capire come funzionano. Non conosco le dimensioni del sistema con cui stai lavorando, ma sono stato con la mia attuale compagnia per un anno e non c'è modo in cui nessuno nel nostro team possa pretendere di sapere come funziona tutto .
Leggi altre domande sui tag programming-practices software