Cosa fai quando ti lanci improvvisamente su un grande progetto?

Question

Recentemente ho iniziato una carriera nello sviluppo di software dopo essermi diplomato un paio di anni fa in CS. L'attuale progetto su cui sto lavorando è un grande progetto in corso che ha le sue origini negli anni '90 con un mix di C, C++ e Java. Sono supportate più piattaforme (UNIX, WIN, ecc.), Vecchie tecnologie in uso come CVS e alcuni documenti datati in alcune aree.

L'estensione delle mie capacità di sviluppo del software deriva dall'andare all'università poiché ho avuto poca esperienza nel mondo reale. Mi sentivo come se avessi una base decente in CS, ma non posso fare a meno di sentirmi leggermente sopraffatto da tutto questo. Sono entusiasta di far parte di qualcosa di così grande ma allo stesso tempo sento che sono molte le informazioni da assorbire.

I miei colleghi sono persone fantastiche e rispondono a molte domande I. Il mio datore di lavoro mi ha assunto sapendo che sono al livello di entrata.

Ho provato a sondare il codice sorgente e ad esaminare come tutto viene creato ma è su una scala che non ho mai visto prima.

In che modo le persone più esperte si situano quando si uniscono a un grande progetto in corso? Quali sono alcuni dei compiti più comuni che svolgi quando diventi sempre più veloce?

Answer 1

Buona domanda. Non ho avuto la tua esperienza esatta, ma in casi come questi mi piace pensare, "come mangi una balena?" La risposta è (prevedibilmente) "un morso alla volta". Le persone ragionevoli non si aspetteranno che tu capisca immediatamente tutto, ma vorranno vedere i progressi. Forse ci sono alcune piccole aree del progetto più grande che non sono troppo complesse, senza troppe dipendenze. Lavora per comprendere uno di questi e sei un 'morso' (e/o 'byte') più vicino alle competenze sull'intero progetto.

Answer 2

Conoscendo tutta la documentazione esistente, proverei a ottenere il quadro generale. Letteralmente.

• generare una TreeMap del codice sorgente

userei GrandPerspective su Mac o WinDirStat su Windows. Vi darà alcune informazioni sulla struttura dei file del progetto (a volte fornisce alcuni suggerimenti sulla struttura del codice). Avendo questo, puoi chiedere ai tuoi colleghi alcuni dei cluster, cosa fanno, come si relazionano tra loro.

• imparare a costruire il progetto

questo è importante per avere la compilazione tutto il tempo se siete in procinto di effettuare qualsiasi modifica. Avere dei test eseguiti al momento della compilazione è sempre una buona cosa, quindi chiedilo pure. Ancora meglio se c'è una specie di server continuous integration sul posto. Se c'è, guarda la sua configurazione - scopri come è fatta la build. Se non ci fosse un server CI, ma hai già le conoscenze su come costruire il progetto, crea un server del genere sul tuo computer locale e mostralo ai tuoi compagni: dovrebbero esserne innamorati.

• sfogliare il codice sorgente con Structure101 o un attrezzo simile

Questo è utile soprattutto per i progetti Java. Questo strumento fa un ottimo lavoro. Ciò ti fornirà maggiori dettagli sulla struttura del codice e, a volte, sull'architettura del sistema.Questa esperienza può essere a volte difficile, si può imparare da questo strumento che un codice è fondamentalmente un Big Ball of Mud;)

• sguardo per le prove, ed esplorare le

Se sarete fortunati ci possono essere alcuni Test JUnit o CPPUnit. Questo è sempre un bene per cercare di capire cosa stanno facendo quei test. Potrebbe essere un buon punto di partenza per esplorare ulteriormente il codice.

Answer 3

Sono d'accordo con il primo commento ma penso anche che devi imparare e vedere il quadro generale in qualche modo. Devi tracciare il flusso principale dal codice almeno.

Answer 4

I miei colleghi sono stati grandi persone e rispondere a un sacco di domande I. Il mio datore di lavoro mi assunto sapendo che sono entry level.

Avete poco di cui preoccuparsi, sei datore di lavoro sa che cosa siete capaci e vostri collaboratori sembrano desiderosi di dare una mano - ad essere onesti la maggior parte degli sviluppatori amano spiegare le cose agli altri ...

Da quello che ho visto, ci vogliono davvero più di 6 anni per diventare pienamente esperti in una lingua, quindi non aspettarti di diventare un guru entro un anno ... e anche questi cosiddetti guru finiscono per imparare qualcosa di nuovo su la loro lingua ogni giorno.

L'apprendimento di un nuovo sistema (grande) richiederà sempre tempo .... i sistemi di solito non sono stati realizzati in 2 settimane ma per molti anni, quindi non aspettatevi di comprenderlo completamente. Alla fine scoprirai cosa fa ogni pezzo pezzo per pezzo.

So come ti senti, perché mi sentivo come che una volta ...

Answer 5

"Ho preso un corso di velocità di lettura e leggere 'Guerra e Pace' in venti minuti. Si tratta di Russia". (Woody Allen)

Sono d'accordo su ciò che gli altri hanno detto prima di me. Ti servono alcuni strumenti che ti offrono una panoramica del codice. Personalmente ho usato inFusion (http://www.intooitus.com/inFusion) perché fornisce anche altri dati interessanti accanto alla struttura.

Answer 6

Il metodo che ha funzionato meglio per me è quello di prendere una copia dal controllo di origine, con l'intenzione di buttare via questa versione ...

Poi cercare di refactoring del codice. È ancora meglio se puoi refactoring il codice che sai che lavorerai in una fase successiva.

Il motivo di questo è efficace perché:

• refactoring ti dà un obiettivo per voi di puntare. Mentre "giocare" e "spezzare" il codice è fantastico - non è focalizzato.
• Per il codice refactor devi veramente capire il codice.
• Il codice refactorato lascia il codice che ha meno concetti da conservare in memoria. Se non capisci una base di codice di grandi dimensioni non è perché sei un laureato - è perché nessuno può conservare più di 7 (dare o prendere alcuni) concetti alla volta.
• Se segui le linee guida per il refactoring corretto significa che dovrai scrivere dei test.Anche se, assicurarsi che si dovrà lavorare sui moduli che si sta verificando come le prove di scrittura può essere molto tempo consumning (anche se molto gratificante)

investono in acquisto di questo libro a un certo punto:

http://www.amazon.co.uk/Refactoring-Improving-Design-Existing-Technology/dp/0201485672

Ma questi collegamenti dovrebbe iniziare:

Segni che il codice ha bisogno di refactoring e cosa refacoring da utilizzare (da refactoring - Martin Fowler) http://industriallogic.com/papers/smellstorefactorings.pdf

Una tassonomia di codice di odori: http://www.soberit.hut.fi/mmantyla/BadCodeSmellsTaxonomy.htm

Buona fortuna !!!

Answer 7

Sono stato nella stessa identica situazione diversi anni fa quando mi sono unito a un progetto software con oltre 50 versioni di controllo di versione ClearCase, 5 milioni di righe di codice, e alcune risalivano agli anni '80.

La prima cosa che ho fatto è stata esaminare tutte le directory controllate dal codice sorgente e fatto un rapido riepilogo della mia migliore ipotesi su ciò che il software in quella cartella faceva e in che lingua era il codice. Puoi fare una buona impressione guardando i nomi dei file e eventuali commenti o documenti in quelle cartelle.

Ho quindi esaminato gli script di compilazione per verificare se fossero sufficientemente leggibili per avere un'idea delle dipendenze tra le diverse parti del codice.

Finalmente - e credo che questo fosse il più prezioso - lanciare un IDE come Eclipse o NetBeans in cima al codice e iniziare a leggerne alcuni pezzi. Avere la possibilità di saltare alla definizione di qualsiasi funzione o classe utilizzando l'IDE consente di spostarsi su una base di riferimento enorme con relativa facilità.

Nel complesso, avere una certa sicurezza - è improbabile che chiunque altro nel progetto conosca tutto il codice, quindi non è necessario. Usa quello che le altre persone hanno detto per avere una buona idea del progetto complessivo e delle interfacce e dei requisiti (se esistono) e cerca attraverso il codice per avere un'idea delle classi e dei metodi più comunemente usati.