Come ti immergi in grandi basi di codice?

Quali strumenti e tecniche usi per esplorare e apprendere una base di codice sconosciuta?

Penso a strumenti come grep , ctags , unit-test, test funzionali, generatori di diagrammi di classi, grafici delle chiamate, metriche di codice come sloccount e così via. Sarei interessato alle tue esperienze, agli aiutanti che hai usato o scritto e alle dimensioni del codice base con cui hai lavorato.

Mi rendo conto che conoscere una base di codice è un processo che avviene nel tempo e la familiarità può significare qualsiasi cosa, da "Sono in grado di sintetizzare il codice" a "Posso refactoring e ridurlo al 30% delle dimensioni ". Ma come iniziare anche?

    
posta miku 23.05.2015 - 14:04
fonte

30 risposte

quello che ho sempre fatto è il seguente:

Apri più copie del mio editor (Visual Studio / Eclipse / Whatever), quindi esegui il debug e esegui le interruzioni di riga attraverso il codice. Scopri il flusso del codice, sovrapponi la traccia per vedere dove sono i punti chiave e vai da lì.

Posso osservare metodo dopo metodo - ma è bello se posso fare clic su qualcosa e poi vedere dove nel codice viene eseguito e seguito. Fammi capire come lo sviluppatore voleva che le cose funzionassero.

    
risposta data 22.09.2010 - 19:27
fonte

Come mangi un elefante?

Un morso alla volta:)

Seriamente, provo prima a parlare con gli autori del codice.

    
risposta data 23.09.2010 - 00:09
fonte

Do I have to hack till I get the job done

In larga misura, sì (mi dispiace).

Approcci che potresti prendere in considerazione:

  1. Cerca di scoprire che cosa dovrebbe fare il codice, in termini commerciali.
  2. Leggi tutta la documentazione che esiste, non importa quanto sia grave.
  3. Parla con chiunque possa sapere qualcosa sul codice.
  4. Scorri il codice nel debugger.
  5. Introduci piccole modifiche e vedi quali interruzioni.
  6. Apporta piccole modifiche al codice per renderlo più chiaro.

Alcune delle cose che faccio per chiarire il codice sono:

  1. Esegui un prettatore di codice per formattare il codice in modo appropriato.
  2. Aggiungi commenti per spiegare cosa penso potrebbe fare
  3. Modifica i nomi delle variabili per renderle più chiare (utilizzando uno strumento di refactoring)
  4. Uso di uno strumento che evidenzia tutti gli usi di un particolare simbolo
  5. Ridurre il disordine nel codice: codice commentato, commenti senza senso, inizializzazioni di variabili inutili e così via.
  6. Modifica il codice per utilizzare le convenzioni del codice corrente (ancora utilizzando gli strumenti di refactoring)
  7. Inizia ad estrarre le funzionalità in routine significative
  8. Inizia ad aggiungere test dove possibile (non spesso possibile)
  9. Sbarazzati dei numeri magici
  10. Riduzione della duplicazione laddove possibile

... e qualsiasi altro semplice miglioramento tu possa fare.

A poco a poco, il significato dietro a tutto dovrebbe diventare più chiaro.

Per quanto riguarda il punto di partenza? Inizia con quello che sai. Suggerisco input e output. Spesso puoi capire come dovrebbero essere e per cosa sono usati. Segui i dati attraverso l'applicazione e vedi dove va e come è cambiato.

Uno dei problemi che ho con tutto questo è la motivazione: può essere una vera e propria baraonda. Mi aiuta a pensare all'intero business come a un puzzle ea celebrare i progressi che sto facendo, non importa quanto piccoli.

    
risposta data 22.11.2013 - 10:24
fonte

La tua situazione è in realtà comune. Chiunque debba entrare in un nuovo lavoro in cui vi sia un codice esistente con cui lavorare, ne tratterà alcuni elementi. Se il sistema è un sistema legacy davvero sgradevole, allora è molto simile a quello che hai descritto. Certo, non c'è mai una documentazione attuale.

Per prima cosa, molti hanno raccomandato Lavorare efficacemente con il codice legacy di Michael Feathers. Questo è davvero un buon libro, con capitoli utili come "Non riesco a ottenere questa classe in un'imbracatura di prova" o "La mia applicazione non ha alcuna struttura" anche se a volte le Piume possono offrire solo più simpatia che soluzione. In particolare, il libro e i suoi esempi sono in gran parte orientati alle lingue delle parentesi graffe. Se stai lavorando con procedure SQL gnarled potrebbe non essere altrettanto utile. Penso che il capitolo "Non capisco abbastanza bene questo codice per cambiarlo", parla del tuo problema. Feathers menziona qui le cose ovvie come prendere appunti e segnare le inserzioni, ma fa anche un buon punto che puoi cancellare il codice inutilizzato se hai il controllo del codice sorgente. Molte persone lasciano sezioni di codice commentate, ma spesso non aiutano.

Successivamente, penso che il tuo approccio suggerito sia certamente un buon passo. Devi capire innanzitutto ad alto livello qual è lo scopo del codice.

Sicuramente lavora con un tutor o qualcuno del team se devi ottenere risposte alle domande.

Inoltre, cogli l'occasione per supportare il codice se vengono rivelati dei difetti (anche se a volte non devi fare volontariato per questo ... il difetto ti troverà!). Gli utenti possono spiegare per cosa utilizzano il software e in che modo il difetto lo sta interessando. Questo può spesso essere un utile bit di conoscenza quando si cerca di capire il significato del software. Inoltre, entrare nel codice con un bersaglio mirato per attaccare a volte può aiutarti a focalizzarti di fronte a "la bestia".

    
risposta data 15.02.2014 - 19:10
fonte

Mi piace fare quanto segue quando ho un file sorgente molto grande:

  • Copia l'intero mess negli appunti
  • Incolla in Word / textmate qualunque sia
  • Riduci le dimensioni del carattere al minimo.
  • Scorri verso il basso osservando gli schemi nel codice

Saresti stupito da quanto stranamente familiare appare il codice quando torni al tuo normale editor.

    
risposta data 13.10.2010 - 21:26
fonte

Ci vuole tempo

Non sentirti troppo affrettato mentre cerchi di capire una base di codice legacy, specialmente se usa tecnologie / linguaggi / framework che non conosci. È solo una curva di apprendimento inevitabile che richiede un po 'di tempo.

Un approccio è quello di andare avanti e indietro tra il codice e le esercitazioni sulle tecnologie correlate. Leggi / guardi il tutorial, poi vai a guardare il codice per vedere come lo hanno fatto i tuoi predecessori, rilevando eventuali somiglianze e differenze, prendendo appunti e facendo domande a qualsiasi sviluppatore esistente.

"Perché hai fatto questa parte in questo modo"

"Ho notato che la maggior parte delle persone online lo fanno in questo modo e tutti voi l'avete fatto in un altro modo. Perché è così?"

"Che cosa ti ha fatto scegliere la tecnologia X sulla tecnologia Y?"

Le risposte a queste domande ti aiuteranno a capire la storia del progetto e il ragionamento dietro le decisioni di progettazione e implementazione.

Alla fine, ti sentirai abbastanza familiare da poter iniziare ad aggiungere / correggere cose. Se tutto sembra confuso o sembra che ci sia troppa "magia" in corso, non hai passato abbastanza tempo a cercarlo, digerirlo e diagrammarlo. La creazione di diagrammi (diagrammi di sequenza, diagrammi di flusso di processo, ecc.) È un ottimo modo per comprendere un processo complesso, in più aiuterà il "prossimo ragazzo".

    
risposta data 28.03.2012 - 20:38
fonte

cscope può fare qualsiasi cosa che Ctags può fare per C, in più, può anche elencare dove viene chiamata tutta la funzione corrente. Inoltre è molto veloce. Scala facilmente a milioni di LOC. Si integra perfettamente con emacs e vim.

Contatore di codice C e C ++: cccc può generare metriche di codice in formato html. Ho usato wc anche per ottenere LOC.

doxygen può generare la sintassi evidenziata e il codice di riferimento incrociato in html. Utile nella navigazione su codebase di grandi dimensioni.

    
risposta data 13.10.2010 - 21:41
fonte

Il modo in cui raccomando con Drupal e non è proprio specifico per Drupal: inizia con il tracker dei problemi. Ci saranno sicuramente segnalazioni di bug vecchie e non chiuse. Puoi riprodurli? Se sì, aggiorna il biglietto confermandolo. Se no, chiudilo. Troverete in questo modo un sacco di modi per utilizzare il software e si può iniziare a sbirciare nella base di codice in cui si blocca. Oppure puoi iniziare a scorrere il codice e vedere come arriva a dove si blocca. In questo modo non inizierai solo a capire il codice base, ma accumulerai anche una tonnellata di karma e le tue domande saranno accolte calorosamente dalla comunità.

    
risposta data 14.05.2011 - 22:09
fonte

Una cosa importante da fare è usare gli strumenti per generare grafici di dipendenza per esplorare dall'alto l'architettura del codice. Per prima cosa visualizzare il grafico tra assembly o jar .NET, questo ti darà un'idea su come sono organizzate le feature e i layer, quindi scavare nelle dipendenze dei namespace (all'interno di uno o pochi parenti o assembly .NET di .NET) per avere un'idea più fine del codice struttura e infine è possibile esaminare le dipendenze delle classi per capire come un insieme di classi collabora per implementare una funzionalità. Esistono diversi strumenti per generare il grafico delle dipendenze, ad esempio NDepend per .NET , ad esempio, che ha generato il grafico sottostante.

    
risposta data 28.06.2011 - 11:45
fonte

Una volta avevo un ingegnere di software piuttosto fantastico che mi diceva che la forma più costosa di analisi e manutenzione del codice era quella di attraversare il codice, riga per riga; certo, siamo programmatori, e questo praticamente arriva con il lavoro. Il mezzo felice, penso, è quello di (in questo ordine): 1. Ottieni un taccuino per creare note su come capire che il codice funziona e aggiungerlo man mano che il tempo passa 2. Fare riferimento alla documentazione sul codice 3. Parla con autori o altri che hanno supportato la base di codice. Chiedi loro una "discarica del cervello" 4. Se sei al punto in cui comprendi alcune delle relazioni di classe a livello di dettaglio, esegui un debugging graduale del codice per fare una sintesi tra come pensi che funzioni il codice e come funzioni effettivamente il codice.

    
risposta data 16.11.2010 - 16:28
fonte

In primo luogo, capisci cosa si intende fare, senza che sia probabilmente priva di senso. Parla con gli utenti, leggi il manuale, qualsiasi cosa.

Quindi premi Esegui e inizia a camminare il codice per quelle che sembrano essere le funzioni chiave.

    
risposta data 16.11.2010 - 16:29
fonte

Dividi e conquista. Osservo ogni funzionalità e il codice associato, li passo e passiamo a quello successivo, costruendo lentamente un'immagine del tutto.

Se il progetto ha avuto test unitari, mi piace anche esaminarli, sono sempre molto rivelatori e illuminanti.

    
risposta data 23.09.2010 - 00:23
fonte
  1. Esegui tutti i test, se ne hai, e vedi quale codice è coperto e quale no.
  2. Se il codice che devi modificare non è coperto, prova a scrivere dei test per coprirlo.
  3. Cambia il codice. Non rompere i test.

Vedi Michael Feathers ' Lavorare efficacemente con il codice legacy

    
risposta data 28.06.2011 - 17:11
fonte

Ecco la mia lista breve:

  1. Se possibile, chiedi a qualcuno di dare una visione di alto livello del codice. Quali modelli sono stati presi in considerazione, quali tipi di convenzioni potrei aspettarmi di vedere, ecc. Questo potrebbe avere qualche giro in quanto all'inizio avrei una storia che man mano che avrò più familiarità con il codice, potrei avere nuove domande chiedere mentre lavoro attraverso la cipolla del progetto preesistente.

  2. Esegui il codice e vedi come sono i sistemi. Certo, potrebbe avere più di un bug, ma questo può essere utile per avere un'idea di cosa fa. Non si tratta di cambiare il codice, ma piuttosto di vedere come funziona. In che modo i vari pezzi si adattano insieme per essere un sistema generale?

  3. Cerca test e altri indicatori di documentazione di base che possano aiutare a costruire un modello mentale interno del codice. Questo è dove probabilmente suggerirei almeno alcuni giorni a meno che non ci sia estremamente poca documentazione e test, naturalmente.

  4. Quanto conosco i linguaggi e le strutture utilizzate in questo progetto? L'importanza qui è la differenza tra guardare alcune cose e andare, "Sì, visto che una dozzina di volte prima e conoscerlo abbastanza bene" e "Che cosa nel mondo viene tentato qui? Chi pensava che fosse una buona idea?" tipo di domande che, anche se non le direi ad alta voce, le penserei soprattutto se guardo il codice legacy che potrebbe essere piuttosto fragile e le persone che lo hanno scritto non sono disponibili o semplicemente non si ricordano perché le cose erano fatte come erano. Per le nuove aree, potrebbe valere la pena dedicare un po 'di tempo in più a conoscere qual è la struttura e quali modelli posso trovare in questo codice.

Ultimo ma non meno importante: conosci le aspettative di coloro che gestiscono il progetto in termini di ciò che dovresti fare in ogni momento, date le seguenti poche idee su cosa ci si potrebbe aspettare:

  • Stai introducendo nuove funzionalità?
  • Stai correggendo i bug?
  • Codice di refactoring? Le norme sono nuove per te o sono molto familiari?
  • Dovresti solo familiarizzare con la base di codice?
risposta data 28.03.2012 - 20:33
fonte

Cerco sempre di iniziare con il punto di ingresso nel programma, dal momento che tutti i programmi ne hanno uno (es. metodo principale, classe principale, init, ecc.). Questo quindi mi indicherà ciò che viene avviato e, a volte, come sono collegate le cose.

Dopo di che prorollo. Il database e DAO sono configurati da qualche parte, quindi ho un'idea di come vengono archiviate le cose. Forse viene avviata anche una sorta di classe di istanza globale, e lì posso capire che cosa viene memorizzato. E con i buoni strumenti di rifrattore, posso scoprire chi chiama cosa.

Quindi provo a trovare dove viene configurata e gestita l'interfaccia, poiché questo è il prossimo punto di accesso alle informazioni. Strumenti di rifattorizzazione, ricerca e debug aiutano nella mia ricerca. Posso quindi capire dove inizia e finisce la gestione delle informazioni, lavorando a modo mio attraverso tutti i file di classe.

Allora provo a scrivere il flusso su un foglio, solo per avvolgere inizialmente la mia mente sulle cose. Il pulsante di invio passa alla verifica generica che viene quindi passata al DAO o al database e quindi viene archiviata nel database. Questa è una grossolana semplificazione della maggior parte delle app, ma è l'idea generale. La penna e la carta sono estremamente utili qui, dato che puoi scrivere tutto velocemente e non preoccuparti della formattazione di un programma che dovrebbe aiutarti.

    
risposta data 22.09.2010 - 23:38
fonte

Direi di iniziare con la documentazione, ecc., ma nella mia esperienza, la profondità della documentazione e delle conoscenze locali è spesso inversamente proporzionale all'età, alle dimensioni e alla complessità di un sistema.

Detto questo, di solito cerco di identificare un paio di thread funzionali. Per funzionale intendo roba come fare il log in, tirare giù un elenco di clienti, ecc. Se i pattern sono coerenti, un thread dovrebbe darti una sezione trasversale del sistema piacevole, non necessariamente completa. Il modo migliore per determinare se i pattern sono coerenti è analizzare una manciata di thread.

Penso che questo sia ovvio ma, a mio parere, è meglio capire il sistema da una prospettiva funzionale piuttosto che da una prospettiva tecnica. Generalmente non mi preoccupo troppo degli strumenti che vengono utilizzati (ORM, librerie di registrazione, ecc.) E ci concentriamo maggiormente sui modelli (MVP, ecc.) Che vengono utilizzati. Nella mia esperienza, gli strumenti sono generalmente più fluidi di questi modelli.

    
risposta data 13.10.2010 - 23:18
fonte

Ho fatto così tanto ...

Ecco il mio attuale approccio per situazioni in cui c'è "qualcosa che funziona", e devi farlo funzionare "in un altro modo".

  1. Ottieni obiettivi, quel sistema dovrebbe risolvere (se non scritto) - scriverlo. Chiedi al manager, agli altri impiegati, anche ai precedenti se disponibili. Chiedi al cliente o cerca qualsiasi pezzo di documentazione.
  2. Ottieni informazioni specifiche. Se non esiste - scrivilo. Non vale la pena chiederlo a qualcuno, come se non esistesse, quindi ti trovi in una situazione in cui agli altri non importa molto. Quindi, l'unico modo per scriverne uno (in seguito sarà molto più facile fare riferimento ad esso).
  3. Prendi il design. Non esiste - scrivilo. Cerca di fare riferimento a qualsiasi documento e codice sorgente il più possibile.
  4. Scrivi una progettazione dettagliata a parte che devi modificare.
  5. Definisci come lo provi. Quindi puoi essere sicuro che il vecchio e il nuovo codice funzionano allo stesso modo.
  6. consente di creare il sistema in un unico passaggio. E prova con il vecchio codice. Mettilo su SVC se non lo è già.
  7. Implementare le modifiche. Non prima.
  8. verifica dopo circa un mese che non vi è nulla di rotto.

Un altro todo opzionale che può richiedere tra ogni passaggio: f off manager (proprietario del progetto) che ti dice che "questi cambiamenti dovrebbero essere fatti già ieri". Dopo pochi progetti, potrebbe anche iniziare ad aiutare a ottenere specifiche e documenti in anticipo.

Ma di solito (specialmente per gli script) non è possibile solo in ambito aziendale (il costo sarà troppo alto, mentre il valore sarà troppo basso). Un'opzione non consiste nel fare alcuna modifica, fino a quando non si raggiunge la massa critica, e il sistema si spegne dalla produzione (ad esempio, il nuovo sistema arriverà) o la direzione deciderà che tutti questi sono degni di fare.

PS: ricordo un codice che è stato utilizzato per 5 client con impostazioni diverse. E ogni cambiamento (nuova funzionalità) era richiesto pensando a "quali parti sono usate" e "quale configurazione ha i client" in modo da non frenare nulla e non il codice copypaste. Mettendo le loro impostazioni per proiettare cvs e scrivere specifiche, questo tempo di pensare si riduce quasi a 0.

    
risposta data 24.12.2010 - 23:02
fonte

Stampa il codice sorgente e inizia a leggerlo. Se è particolarmente grande, stampa solo alcune parti di esso per comprenderlo meglio e creare tutte le note / commenti che ti servono.

Traccia il programma partendo dall'inizio della sua esecuzione. Se sei assegnato a una particolare parte della base di codice, traccia l'esecuzione all'interno di quella parte e scopri quali strutture di dati vengono utilizzate.

Se stai utilizzando un linguaggio orientato agli oggetti, prova a creare un diagramma generale della classe. Questo ti darà una buona panoramica di alto livello.

Sfortunatamente, alla fine, dovrai leggere più codice possibile. Se sei fortunato, i precedenti programmatori hanno scritto tutta la documentazione possibile per aiutarti a capire cosa sta succedendo.

    
risposta data 27.02.2012 - 04:14
fonte

La prima cosa che devi fare quando impari un nuovo codice è apprendere cosa deve fare, come è usato e come usarlo. Quindi inizia a guardare la documentazione architettonica per sapere come è strutturato il codice, guarda anche a come il database a questo punto. Allo stesso tempo stai imparando l'architettura è un buon momento per rivedere i flussi di processo o utilizzare i documenti del caso. quindi inizia a immergerti e leggi il codice dopo aver compreso il quadro generale, ma solo il codice relativo a qualsiasi lavoro che potresti fare su questo codice, non prova solo a leggere tutto il codice. È più importante sapere dove deve essere eseguito il codice X che esattamente come X è fatto, il codice è sempre lì per dirti come se lo trovi.

Trovo che solo il tentativo di entrare e leggere il codice senza un obiettivo oltre l'apprendimento del codice sia generalmente improduttivo, provare a fare piccole modifiche o rivedere il codice delle modifiche di qualcun altro è un uso molto più produttivo del tuo tempo.

    
risposta data 28.03.2012 - 20:38
fonte

Se la base di un codice è grande, focalizza l'attenzione sulle parti che stanno attualmente lavorando. Altrimenti ti sentirai sopraffatto e forse la tua testa potrebbe esplodere. Penso che qualche panoramica di alto livello sia utile (se disponibile), ma è probabile che trascorrerai molto tempo nel debugger per seguire il flusso del programma. È una buona idea avere una panoramica dell'applicazione e vederla usata, così puoi capire come / che / perché il codice viene usato.

Di solito eseguo una sorta di strumento di complessità del codice sul codice per dirmi dove si trovano le aree problematiche. Le aree che hanno un punteggio elevato sono probabilmente molto difficili da aggiornare. Per esempio, mi sono imbattuto in una funzione che ha ottenuto un punteggio di 450 sulla scala ciclomatica. Abbastanza sicuro, centinaia di IF. Molto difficile da mantenere o modificare. Quindi preparati al peggio.

Inoltre, non aver paura di porre domande agli sviluppatori esistenti, specialmente se hanno lavorato al sistema. Tieni i tuoi pensieri interiori a te stesso e concentrati sulla risoluzione dei problemi. Evita commenti che potrebbero far arrabbiare gli altri sviluppatori. Dopotutto, potrebbe essere il loro bambino e a nessuno piace essere detto che il bambino è brutto.

Fai piccoli passi, anche il più piccolo cambiamento di codice può avere un grande impatto.

Trovo utile venire con i flussi del codice del programma, quindi se faccio delle modifiche, posso fare ricerche di dipendenza per vedere quali metodi / funzioni chiamano cosa. Supponiamo che io stia cambiando il metodo C.

Se solo 1 metodo / funzione chiama C, allora è un cambiamento abbastanza sicuro. Se 100s di metodi / funzioni chiamano C, allora sarebbe di maggiore impatto.

Speriamo che il tuo codice base sia ben progettato, scritto e mantenuto. Se è così, ci vorrà del tempo per capirlo, ma alla fine la marea verrà girata.

Se è una grande palla di fango, potresti non capire (o voler capire) il suo funzionamento interno.

    
risposta data 28.03.2012 - 20:50
fonte

Alcune cose che faccio ...

1) Utilizzare uno strumento di analisi del codice sorgente come Source Monitor per determinare le varie dimensioni dei moduli, le metriche di complessità ecc. avere un'idea del progetto e aiutare a identificare le aree che non sono banali.

2) Analizza il codice dall'alto verso il basso in Eclipse (utile per avere un editor che può consultare i riferimenti, ecc.) fino a Vengo a sapere cosa sta succedendo e in che punto del codice base.

3) Occasionalmente, disegno diagrammi in Visio per avere un quadro migliore dell'architettura. Questo può essere utile anche per gli altri sul progetto.

    
risposta data 16.02.2014 - 01:54
fonte

Questo succede molto. Fino a quando non ho iniziato a lavorare su una piattaforma open source, non penso di aver mai iniziato un lavoro che non è iniziato con l'ammissione che il codice aveva alcune "stranezze".

Puoi fare un lungo cammino con un debugger di passi e molta tenacia. Sfortunatamente spesso ci vuole tempo ed esperienza per imparare una particolare palla di fango e anche dopo anni ci può essere ancora un sottosistema che si sviluppa su cui nessuno ha alcuna conoscenza.

    
risposta data 24.12.2010 - 15:55
fonte

Ti incoraggio a scrivere dei test unitari prima di cambiare qualsiasi cosa nella palla di fango. E solo cambia abbastanza del codice al momento per far passare i test. Come refactoring, aggiungi i test unitari prima della mano in modo che tu sappia che la funzionalità aziendale non è stata smentita dal refactoring.

La coppia sta programmando un'opzione? Avere un'altra persona a rimbalzare idee è una grande idea per affrontare quella quantità di cattivo.

    
risposta data 25.12.2010 - 06:22
fonte

Ecco una procedura che usiamo per eliminare i duplicati.

  • seleziona un prefisso di commento standard per i duplicati (usiamo [dupe] subito dopo il marcatore del commento;
  • scrivi le specifiche con i tuoi team sui nomi da utilizzare per la procedura duplicata;
  • primo turno: tutti prendono alcuni file e aggiungono [dupe][procedure_arbitrary_name] prima della procedura duplicata;
  • secondo giro: ognuno prende una procedura, o un sottoinsieme di procedure, e assegna un valore che indica l'ordine di probabilità delle diverse implementazioni per lo stesso scopo (la stringa sarà quindi: [dupe][procedure_arbitrary_name][n] );
  • terzo round: il responsabile di ogni procedura lo riscrive nella classe pertinente;
  • quarto round: grep happy!
risposta data 25.12.2010 - 06:59
fonte

Penso che una delle cose più importanti sia prendere una semplice funzionalità, scegliere la più semplice che si possa pensare e implementarla. Se esiste una lista dei desideri mantenuta, usarla o parlare con qualcuno che abbia familiarità con la base di codice e convincerli a suggerire una funzione. Di solito mi aspetterei che questo sia un cambiamento con 5 ~ 20 LOC. Il punto importante non è che si sta aggiungendo una funzione molto elaborata ma che si sta lavorando (o meglio si aggrappa :)) alla base del codice e passando attraverso l'intero flusso di lavoro. Dovresti

  1. Leggi il codice per comprendere il componente che stai modificando
  2. Modifica il codice e scopri come influisce sul sistema circostante.
  3. Verifica la modifica e identifica in tal modo in che modo i componenti interagiscono tra loro
  4. Scrivi il caso di test e, auspicabilmente, interrompi uno o due test case in modo da poterli risolvere e capire gli invarianti del sistema.
  5. Costruisci la cosa o vedi l'elemento di configurazione costruiscilo e quindi spediscilo

La lista continua, ma il punto è che un mini progetto come questo ti porta attraverso tutti gli elementi della tua lista di controllo per fare conoscenza con un sistema e porta anche a una modifica produttiva.

    
risposta data 28.03.2012 - 20:41
fonte

Una piccola cosa che volevo aggiungere:

Uno strumento che ho iniziato a utilizzare recentemente per questo tipo di problema che ha contribuito enormemente alla mappatura mentale. Invece di provare a racchiudere tutti i dettagli di come qualcosa viene implementato nella mia testa, costruirò una mappa mentale che descriva come funziona il sistema che sto passando. Mi aiuta davvero a capire più a fondo cosa sta succedendo e cosa ho ancora bisogno di capire. Mi aiuta anche a tenere traccia di ciò che ho bisogno di cambiare ad una scala molto precisa.

Raccomando di utilizzare aereo gratuito tra le numerose opzioni di mappatura mentale.

    
risposta data 17.10.2012 - 03:34
fonte

Non ci sarà alcuna documentazione o ci sarà poca documentazione, o non sarà aggiornata. Trova tutta la documentazione che esiste. Se si trova nel repository di un gruppo, non fare una copia. In caso contrario, mettilo lì e chiedi al tuo manager il permesso di organizzarlo, magari con un po 'di supervisione.

Porta tutto nel repository del team e aggiungi un glossario. Tutte le basi hanno un gergo; documentarlo nel glossario. Crea sezioni per strumenti, prodotti, specifiche del cliente, ecc.

Crea / Aggiorna un documento di creazione dell'ambiente software. Tutti gli strumenti, i quirk, le opzioni di installazione ecc. Vanno qui.

Quindi carica un documento introduttivo con "ProductName" o simili. Lascia che sia solo il flusso mentale e si auto-organizzi nel tempo. Quindi consulta i documenti non aggiornati e ripristinali. Gli altri sviluppatori lo apprezzeranno, contribuirai in modo unico mentre impari il codice. Soprattutto, documenta tutte le cose che ti pungono o che hanno un nome errato o che sono contro-intuitive.

Una volta terminata la curva di inclinazione, non preoccuparti dell'aggiornamento della documentazione. Lascia che il prossimo nuovo ragazzo lo faccia. Quando arriva, indirizzalo al tuo lavoro. Quando ti infastidisce continuamente per avere delle risposte, non rispondergli. Piuttosto, aggiungi la domanda alla tua documentazione e poi consegnagli l'url. Canna da pesca.

Un effetto collaterale è che avrai creato uno strumento a cui puoi riferirti da mesi quando dimentichi.

E sebbene non si tratti di documentazione, un problema correlato è costituito dalle piccole e stravaganti procedure manuali che fanno i tuoi compagni di squadra. Automatizzali con batch, script sql e simili, e condividi anche quelli. Dopotutto, la conoscenza procedurale è discutibilmente grande quanto la conoscenza dichiarativa in termini di produttività in un nuovo ambiente. Qualunque cosa sia, non farlo; piuttosto, lo script, ed esegui lo script. La canna da pesca colpisce ancora.

    
risposta data 16.05.2013 - 22:53
fonte

Ho scritto un post abbastanza lungo su questo argomento. Ecco un estratto

Ho pensato a questo problema per un bel po '. Ho deciso di scrivere la mia soluzione personale come processo generale. I passaggi che ho documentato sono i seguenti:

  1. Crea foglio di vocabolario
  2. Scopri l'applicazione
  3. Sfoglia la documentazione disponibile
  4. Presupposti
  5. Trova librerie di terze parti
  6. Analizza codice

Questo processo è scritto nel contesto di una grande applicazione desktop, ma le tecniche generali sono ancora applicabili alle applicazioni web e ai moduli più piccoli.

tratto da: Un processo per l'apprendimento di un nuovo codebase

    
risposta data 09.06.2013 - 02:33
fonte

Ci sono alcuni piccoli consigli che posso condividere.

Per un prodotto esistente, inizio a testarli intensamente. Se scegli / assegni un'attività, mi concentrerò maggiormente sulla particolare funzionalità.

  • Il prossimo passo sarebbe trovare il codice in cui posso entrare e iniziare a esplorare Lungo la strada troverò i moduli dipendenti, le librerie, i framework ecc.

  • Il prossimo passo sarebbe creare un semplice diagramma di classe con le sue responsabilità (come le carte CRC)

  • Iniziare a fare piccole modifiche o prendere piccoli bug da correggere e commettere. Quindi possiamo imparare il flusso di lavoro del progetto; non solo il codice. Spesso i prodotti di grandi dimensioni avranno una sorta di conservazione dei libri a fini di autorizzazione e audit (ad esempio i progetti sanitari)

  • Parla con le persone che stanno già lavorando al progetto. Esprimi le tue idee, i tuoi pensieri e in cambio ottieni la loro esperienza e opinioni su come lavorare con questo progetto per lungo tempo. Questo è molto importante perché ti aiuta anche ad andare d'accordo con il team.

risposta data 22.08.2013 - 08:20
fonte

È passato molto tempo da quando mi sono dovuto immergere in una grande base di codice. Ma negli ultimi due anni ho provato molte volte a creare nuovi sviluppatori in team in cui disponevamo di una base di codice esistente piuttosto ampia.

E il metodo che abbiamo usato con successo, e direi che è il modo più efficace senza dubbio IMHO, è la programmazione delle coppie.

Negli ultimi 12 mesi, abbiamo avuto 4 nuovi membri nel team, e ogni volta il nuovo membro si assocerebbe a un altro membro che conosce bene la base del codice. All'inizio, il membro del team più vecchio avrebbe avuto la tastiera. Dopo circa 30 minuti passeremmo la tastiera al nuovo membro, che lavorerebbe sotto la guida del vecchio membro del team.

Questo processo ha avuto un discreto successo.

    
risposta data 22.08.2013 - 14:44
fonte

Leggi altre domande sui tag