Lavorando sul codice di qualcun altro [chiuso]

Non ho quasi un anno di esperienza nella programmazione. Dopo aver iniziato a lavorare, la maggior parte delle volte lavoravo sul codice di qualcun altro, aggiungendo nuove funzionalità rispetto a quelle esistenti o modificando quelle esistenti. Il tizio che ha scritto il codice attuale non funziona più nella mia azienda. Sto facendo fatica a capire il suo codice e a fare i miei compiti. Ogni volta che ho provato a modificare il codice, ho in qualche modo pasticciato con le funzionalità funzionanti. Cosa devo tenere a mente mentre lavoro sul codice di qualcun altro?

Il codice ha test unitari? In caso contrario, ti consiglio vivamente di iniziare ad aggiungerli. In questo modo, è possibile scrivere nuove funzionalità / correzioni di bug come test non riusciti e quindi modificare il codice superato. Più di quelli che crei, maggiore sarà la sicurezza che il tuo codice aggiunto non abbia rotto qualcos'altro.

Scrivere unit test per il codice che non capisci completamente ti aiuterà a capire detto codice. Naturalmente, i test funzionali dovrebbero essere aggiunti se non esistono già. La mia impressione era che quelli già esistessero dalla domanda del PO. Se mi sbaglio su questo punto, allora questi test funzionali dovrebbero essere il tuo primo passo.

Eagle76dk ha un grande punto su come coinvolgere il tuo manager per fare questo lavoro - maggiori dettagli nel post di Eagle76dk.

Inoltre, mentre scrivi questi test, ti incoraggio a provare a scrivere i test in modo che verifichino il comportamento aziendale che il metodo potrebbe aver tentato di eseguire, non il comportamento del codice. Inoltre, non dare per scontato che i comportamenti aziendali che vedi nel codice siano quelli corretti - Se hai qualcuno che potrebbe dirti cosa dovrebbe fare l'applicazione, questo è in molti casi più prezioso di quello che il codice potrebbe dirti.

Oltre a un'altra risposta che menziona i test unitari, ti suggerisco di assicurarti che tutto sia sotto controllo di versione in modo da poter ripristinare facilmente le modifiche. E apportare piccole modifiche per rendere il codice più gestibile.

Secondo me, il modo più veloce per imparare il codice di qualcun altro, (specialmente quando le modifiche innesca comportamenti inaspettati come descrivi) è quello di scorrere il codice usando un debugger .

Inizia passando attraverso quello che sembra essere il ciclo principale / i metodi principali del programma. Utilizzare il passo nella e uscire funzioni per vedere cosa fa metodi diversi. Questo ti insegnerà la struttura generale del codice.

Dopodiché, dividi e conquista avanzando e imparando le diverse parti del programma a un livello più profondo. Nella maggior parte dei debugger è possibile studiare le variabili e i loro valori correnti . Studia come cambiano e quando.

Stabilire punti di interruzione sui metodi che innescano comportamenti che ti riguardano. Ad esempio, se si sta tentando di modificare un testo nel programma e il testo continua a tornare al valore originale, impostare i punti di interruzione in tutti i punti in cui viene modificato il testo o provare a spostare tutte queste modifiche in un unico metodo. Utilizzare lo stack di chiamate per vedere da dove viene chiamato questo metodo, ecc. Ecc.

Se la modifica di una riga di codice provoca cambiamenti imprevisti in altri punti, inserire un punto di interruzione su quella riga e vedere cosa succede lì, ad esempio controllando i valori delle variabili correnti nell'ambito, usando step in o lo stack di chiamate per vedere da dove la chiamata arrivò.

In questo modo, inizierai a imparare la struttura del codice in modo sorprendentemente veloce. Ho iniziato proprio come hai fatto con i miei primi lavori di programmazione, con un sacco di codice che era stato scritto molti anni fa ed è stato modificato da molte persone nel corso di molti anni. Il codice non era mio solo da lì, dove altre persone ci lavoravano allo stesso tempo. Non ho potuto riscrivere tutto a quel punto. Scrivere test per tutto quel codice mi avrebbe richiesto mesi o anni. Il debugger mi ha davvero salvato, non so come avrei imparato il codice senza di esso ...

La prima cosa da tenere a mente è che si impiega più tempo a leggere il codice che a scrivere il codice. Trascorri il tempo per capire come ha lavorato l'altro ragazzo - il suo stile e il suo approccio ai problemi.

Cerca di adottare il più possibile lo stile esistente, altrimenti il ​​ragazzo dopo ti sarà adattato il doppio.

Avere a che fare con il codice di qualcun altro è la norma, non l'eccezione, è necessario diventare abili nel capire come l'altro ragazzo avrebbe risolto un problema o implementato una funzionalità. Una volta fatto, troverai più facile gestire il suo codice.

Non essere troppo veloce per presumere che il codice dell'altro ragazzo puzzi.

Ma sii sempre sospettoso.

Ma sì, ci vuole tempo per capire il codice di un altro sviluppatore. Più una funzione o un oggetto viene utilizzato da più parti del sistema, più è necessario fare attenzione. Se riesci a risolvere il problema più vicino al sintomo, a volte può essere utile. Ad esempio, normalizzare i dati in arrivo da un altro oggetto sul lato dell'oggetto recinto del problema dopo che i dati sono stati consegnati ma prima che accada qualsiasi altra cosa.

È un brutto segno quando cambiare una cosa ne interrompe un'altra inaspettatamente. Se hai altri sviluppatori più esperti su cui puoi fare affidamento per un aiuto, ti consiglio di farli esaminare le cose che ti causano problemi. Per lo meno puoi prendere alcune cose guardandole eseguire il debug.

In un mondo ideale, tutto il codice scritto da un determinato sviluppatore sarà ben documentato, ben strutturato e testato in modo comprensibile, sia con strumenti automatici come test unitari sia usando script di casi che un utente esegue per verificare che si ottenga il risultato atteso.

Tuttavia, la prima cosa che imparerai è che non viviamo in un mondo ideale!

Molti sviluppatori non documentano correttamente il loro codice, se non altro, mescolano la logica aziendale con il codice non correlato e l'unico test che eseguono è una rapida analisi di ciò che si aspettano essere il normale caso d'uso.

Quando si lavora con codice come questo, la prima cosa da fare è stabilire cosa deve fare. Se ci sono commenti possono darti degli indizi, ma non contare su di esso. È la mia esperienza che molti programmatori non sono bravi a spiegarsi e anche se lasciano commenti potrebbero non avere senso. Tuttavia, a meno che tu non sia l'unico programmatore dell'azienda, sicuramente qualcuno deve avere almeno un'idea di base su cosa serve il codice e cosa deve fare. Chiedi in giro!

Se hai dei test unitari, ti renderanno la vita molto più facile. In caso contrario, parte dell'apprendimento del codebase può comportare la scrittura di unit test per il codice già esistente. Normalmente questa non è considerata una buona pratica perché se si scrivono unit test per adattarsi al codice esistente, si finiranno con unit test che pensano che il codice funzioni così com'è (verranno scritti per assumere che il comportamento che in realtà è un bug è corretto), ma almeno ti dà una base. Se in seguito scopri che alcuni comportamenti che ritieni fossero corretti sono in realtà errati, puoi modificare il test unitario per verificare quale sia il risultato atteso anziché il risultato che il codice fornisce ora. Dopo aver effettuato un test unitario, è possibile apportare modifiche e valutare quali effetti collaterali apportano eventuali modifiche.

Infine, la migliore risorsa che hai quando hai a che fare con un pezzo di codice non documentato è chiedere agli utenti finali. Potrebbero non sapere nulla del codice, ma sanno cosa vogliono che faccia l'applicazione. La raccolta dei requisiti è la prima fase di qualsiasi progetto e parlare con i potenziali utenti del sistema da sviluppare è sempre una parte importante di questo. Basti pensare che sta facendo la fase di acquisizione dei requisiti per un nuovo progetto che sembra essere già stato costruito.

Tieni presente che anche un codice ben scritto e ben documentato può essere difficile da comprendere per un estraneo. Il codice è essenzialmente un'espressione di come la persona che l'ha scritto stava pensando in quel momento, e ognuno ha il proprio processo di pensiero unico. Dovrai imparare ad essere un po 'paziente e ad essere un detective. Essere in grado di entrare nel processo di pensiero di un'altra persona è difficile, ma è un'abilità essenziale per un programmatore che fa manutenzione sul codice esistente. Poiché la maggior parte della codifica (circa il 70%) è legata al mantenimento del codice esistente, è un'abilità importante da imparare.

Oh, e ora che hai visto il dolore che può causare il codice scarsamente documentato, non testato e confuso, non lo farai al prossimo povero sviluppatore di venire, giusto? :) Impara dagli errori del tuo predecessore, commenta bene il tuo codice, assicurati che ogni modulo abbia una responsabilità chiaramente definita a cui si attacca e assicurati di avere un set completo di test unitari che scrivi prima (per le metodologie TDD) o almeno a fianco del codice in fase di sviluppo.

Tieni presente che la capacità di leggere il codice che non hai scritto è un'abilità molto preziosa, probabilmente più preziosa della scrittura di codice. Sfortunatamente, questo è ampiamente sottovalutato e poco istruito nelle scuole.

Quello che sto cercando di dire è che è normale che tu non capisca sempre il codice quando lo leggi la prima volta (proprio come è normale che non scrivi il codice perfetto la prima volta). Se accetti che ci vuole tempo per ottenere un codice straniero, non ti dispiacerà fare lo sforzo extra. Un piccolo riassunto:

• I test unitari sarebbero ideali, ma non sempre realistici; specialmente se lavori in una grande organizzazione con una pesante burocrazia.

• Impara a usare correttamente il tuo sistema di controllo versione; non spezzerai mai l'esistente (non proprio mai , ma è una buona rete di sicurezza).

• Non dare per scontato che sia cattivo semplicemente perché non lo capisci all'istante. Non dare per scontato che sia buono semplicemente perché funziona. L'importante è capire lo stile di codice del manutentore precedente e adattare le linee aggiunte al suo stile. Il manutentore che ti segue ti ringrazierà per questo.

• In alcune aziende, sfortunatamente, la difficoltà di leggere il codice può essere sottovalutata. Questo è comune nelle grandi aziende con processi rigidi. Preferiscono (implicitamente) spesso che tu invii codice che funzioni rapidamente piuttosto che impiegare il tuo tempo a scrivere qualcosa di pulito. Lascio a te decidere dove si trova la tua squadra su questo punto.

• Infine, non dimenticare mai che leggere il codice è un'abilità . Più lo fai, meglio ci riuscirai. Un altro modo per dirlo è che l' unico modo per diventare bravi è praticarlo molte volte. Come menzionato sopra, leggere il codice è e sarà una parte molto più grande del tuo lavoro rispetto alla scrittura.

A giudicare dai tuoi problemi con la rottura involontaria di cose, suppongo che il codice non sia coperto da test automatizzati. Il passo # 0 sarebbe quello di ordinare e leggere immediatamente Lavorare in modo efficace con il codice legacy di Michael Feathers. È semplicemente inestimabile.

I passaggi di base che suggerirei:

• Coprire il codice con test che coprono la funzionalità corrente.
• Refactor fino a quando comprensibile.
• Scrivi un test per la funzionalità nuova o modificata.
• Implementa la nuova funzionalità.
• Rifattore fino alla soddisfazione.

Lascio deliberatamente fuori specificando il sapore dei test (unità, integrazione, ...) - ottengo solo una sorta di copertura di test automatizzata.

(e, sì, segui lo stile di codifica in termini di layout e denominazione)

Come accennato in precedenza: benvenuto nel mondo reale. Posso solo essere d'accordo con le risposte precedenti. Vorrei solo estendere la risposta con la mia esperienza di lavoro sulle stime dei tempi.

Un buon suggerimento per chiarire il tuo capo, ci vorrà del tempo per imparare come pensano gli altri sviluppatori. Di solito sperimenterai che la soluzione attuale spesso dipende dall'età e dall'esperienza dello sviluppatore.

Se sei fortunato, il compito da svolgere deve essere analizzato e la comprensione della documentazione ti aiuterà molto (ma spesso non è così).

La mia esperienza è che quando si modifica il codice degli altri, provare a non modificare il codice che non coinvolge l'attività corrente. Potresti conoscere una soluzione migliore o potrebbe essere scritta in un modo più intuitivo, ma cambiarla spesso porta a problemi come:

• Il compito richiederà più tempo e il tuo capo non lo capirà.
• Il codice modificato deve essere testato e costa. L'attuale soluzione è stata testata e approvata.
• Sarà difficile vedere quali modifiche risolvono il compito corrente e quali sono le correzioni "solo".

Ma non esitare a dirlo al tuo capo, se vedi qualcosa che pensi debba essere diverso (mostra solo che puoi pensare).

Infine, assicurati di avere abbastanza tempo per realizzare la soluzione. Una soluzione più veloce arriva con l'esperienza. Ma raramente esiste una soluzione rapida, poiché questa è la prima / principale ragione di errori e codice non mantenibile.

Pensalo come eseguire un'operazione su una persona.

Cerchi il problema che devi risolvere e noti che la maggior parte delle arterie, ecc. Non sono impostate nel modo in cui lo faresti, quindi le tagli e le tagli intorno fino a quando non ti sembra giusto, quindi risolvi il problema.

Sorprendentemente il tuo paziente muore quasi immediatamente.

Le applicazioni legacy sono le stesse. Hanno già un modo di lavorare: è necessario comprendere i vari componenti del software e come si relazionano tra loro e quindi apportare le modifiche in modo che funzioni allo stesso modo. Non è eccitante come scatenare la tua creatività, ma puoi farlo su progetti personali.

Chiederei a un ingegnere senior di sedersi con te per circa un'ora ogni lunedì e spiegare un aspetto diverso del sistema. Prendi appunti su ciò che dice e inviali via email a lui e al tuo manager per vedere se il tuo manager ha qualcosa da aggiungere. In questo modo dovresti alzarti abbastanza rapidamente.

Per quanto riguarda come non rompere le cose, prima di tutto assicurati di capire cosa fa il sistema. Prova prima - apporta le modifiche - prova successivamente. Non ci sono formule magiche; man mano che acquisisci esperienza, migliorerai - o verrai licenziato immagino!

Una cosa che non ho davvero visto toccato qui - non lavorare su un'isola.

A meno che tu non sia l'unico programmatore del tuo abbigliamento, ci sarà sicuramente qualcuno che ha più esperienza di te e molto probabilmente molte persone su cui puoi appoggiarti.

Fare domande. Molti di loro.

Non preoccuparti di "irritare" qualcun altro (entro limiti ragionevoli) - Preferirei che qualcuno mi interrompesse per una o due domande durante un normale ciclo di sviluppo, piuttosto che dover spegnere un incendio in un ambiente di produzione in seguito.

Quando sei pronto per fare il check-in, rivedi con il / i tuo / i mentore / i. Dovrebbero essere in grado di dirti non solo se qualcosa romperà qualcos'altro, ma, soprattutto, perché. La revisione del codice renderà anche il mentore un programmatore migliore, dandogli una visione nel sistema che altrimenti non potrebbero guardare altrettanto spesso.

Ricorda: non stai solo imparando il sistema come ogni nuovo dipendente dovrebbe fare, ma stai anche imparando come diventare un programmatore.

E tra cinque anni, incoraggia il nuovo New Guy a usarti come mentore.

Quando si tratta di debug del codice, ricorda: c'è sempre un motivo . Quando hai provato a trovare e correggere lo stesso stupido bug per alcuni giorni e non stai facendo alcun progresso, è allettante iniziare a pensare a uno o più di:

• Non sono abbastanza intelligente da capire come funziona questo codice

• Il tizio che ha scritto questo codice non aveva idea di cosa stesse facendo

• È coinvolta la magia: magia molto nera

Quelle sono tutte forme di arrendersi. L'antidoto è ricordare sempre che i computer sono deterministici: c'è sempre una ragione per quello che fanno. Il codice può avere l'odore della bassa marea in una fabbrica di pesce e assomigliare a una gigantesca ciotola di linguine, ma essendo incessantemente razionale e mantenendo una mente aperta, lo capirai .

Sia che tu scriva unit test dove possibile o scrivi piccole applicazioni che coinvolgono il codice che stai modificando, dovrai guardare, capire e quindi documentare la logica.

Se il codice funziona principalmente - sembra che funzioni - allora conserverei lo stile della formattazione del codice per quel modulo, che sia il tuo stile o meno. Mantiene le cose uniformi. Tuttavia, i buoni commenti non passano mai di moda.

Consiglio un sistema di test e una piattaforma di test, in cui è possibile modificare e testare questo codice, senza interrompere la produzione.

Se riesci a rimuovere elementi del codice in una libreria, lo farei, a meno che tu non stia lavorando su una libreria.

Nel tempo, una volta compresa la logica, è possibile riscrivere e testare.

Questo consiglio è dettato dalla lingua che stai usando, dalla possibilità di ottenere un banco di prova e da altri vincoli che hai.

Prova a utilizzare alcuni strumenti di analisi del codice per trovare codice inutilizzato che può essere eliminato - quindi almeno non devi preoccuparti di questo codice.

È stato osservato sopra che è necessario comprendere lo scopo del sistema, non solo i dettagli del codice. Un programmatore con sufficiente esperienza per scrivere un sistema di immissione degli ordini è generalmente a suo agio con la parte "avanzamento", che prevede la selezione dei prodotti, la formattazione di una fattura e l'elaborazione del pagamento. Il punto in cui si bloccano è quando l'utente decide "non importa" e inizia a eseguire il backout delle transazioni, oppure quando commette un errore nell'elaborazione dei pagamenti e preme il pulsante "indietro". A quel punto molti programmatori vengono confusi, perché vedono il codice "mostrarsi dal nulla" e non riescono a capire perché sia ​​lì.

In breve, devi capire non solo il "flusso normale", ma tutto il backtracking necessario se qualcuno commette un errore o cambia idea. Ciò peggiora ulteriormente con le sostituzioni del supervisore, in cui parte del codice può essere eseguito solo con determinati privilegi dell'account.

Se qualcuno scrive 10.000 righe di codice all'anno e un'applicazione ha una "vita" di dieci anni, un programmatore responsabile della raccolta del lavoro di qualcun altro potrebbe dover comprendere 100.000 righe di codice. Dividilo per 50 righe per pagina per 2000 pagine. Se il programma è scritto in uno schema di progettazione, il programmatore scoprirà che la comprensione di un "blocco" porta almeno a una comprensione generale della maggior parte del resto. In caso contrario, è necessario leggere l'ultima riga.

Alcuni programmatori "fanno solo quello che viene loro detto" e scrivono spaghetti. Non capiscono mai il 'quadro generale', semplicemente correggono quando gli utenti si lamentano. In tali circostanze è una buona idea iniziare a migrare tutto ciò che è possibile verso uno schema adeguato. Alla fine questo può significare ricodificare cose che non sono "rotte". Non ti preoccupare, assicurati solo che fino a quando è il tuo progetto sia progressivamente più mantenibile.

Ci sono alcune risposte davvero belle qui. Ma penso che valga la pena menzionare quanta familiarità con buoni modelli di progettazione può aiutare, leggere (ben scritto) codice esistente e scrivere codice leggibile.

Naturalmente può essere molto confuso quando si incontra un SomethingFactorycodice esistente, che in realtà non segue il modello di fabbrica . Tuttavia, per quanto il team e il framework lo consentano, può essere utile limitare al minimo tali casi.

Seguire i modelli di progettazione (laddove le esigenze aziendali lo consentano) può anche ridurre significativamente la duplicazione del codice che a sua volta riduce i bug su future modifiche.

Alcune buone fonti sui modelli di progettazione sono

http://sourcemaking.com/design_patterns

http://www.oodesign.com/

e ovviamente il libro

http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612

Tracciare il flusso di controllo tra i metodi è molto importante nello sviluppo di una mappa mentale della logica aziendale.

La nostra soluzione si basa sul riconoscimento che una delle poche informazioni attendibili disponibili quando ci si avvicina a un sistema legacy è il sistema in esecuzione stesso. Il nostro approccio reifica le tracce di esecuzione e utilizza la programmazione logica per esprimere test su di esse.

La generazione di un modello di dati del flusso di lavoro è il modo migliore per analizzare tutti i percorsi del codice:

In pratica, la revisione del codice diventa ingombrante nei flussi di lavoro scientifici legacy. L'origine di tali flussi di lavoro significa che le pratiche di ingegneria del software potrebbero non essere state applicate durante lo sviluppo, portando a una base di codice che è effettivamente offuscata. Sebbene l'analisi statica abbia tecniche ben sviluppate per l'analisi del flusso di dati, non supportano il comportamento nei flussi di lavoro del mondo reale. Ad esempio, quando un file di configurazione deve essere caricato per determinare come devono essere elaborati i dati o quando viene utilizzata la valutazione del codice dinamico.

E visualizzare il flusso di lavoro è l'ideale:

Un motivo comune, prestandosi allo sviluppo visivo, è la presentazione di un flusso di lavoro sotto forma di grafico. Questo protegge l'utente dalla sottostante complessità delle risorse e dell'esecuzione

Riferimenti

• Comprensione dei flussi di lavoro legacy tramite Runtime Analysis (pdf)
• Test logici basati sulla traccia del sistema legacy orientato agli oggetti (pdf)
• console.trace () - API Web | MDN
• Traccia delle chiamate del metodo tramite proxy
• Come spiare i tuoi metodi Ruby
• Facile traccia delle chiamate di funzioni nidificate in Python - il sito Web di Eli Bendersky
• Registrazione dell'entrata / uscita del metodo - Mebyon Kernow
• Traccia: strumentazione per mostrare chiamate di funzione
• -Xtrace -
• GitHub - johnno1962 / SwiftTrace: invocazioni del metodo Trace Swift e Objective-C
• Debug :: Trace - Estensione Perl per tracciare le chiamate di subroutine - metacpan.org

Assicurati di utilizzare un programma che ti aiuti a trovare elementi nel file corrente. Niente è peggio che sapere che cosa stai cercando è nel file corrente, ma scorri e scorri e non riesci a trovarlo. Una vista di struttura nello strumento che usi per modificare il codice aiuta davvero a risolvere questo problema.