Capire il codice degli altri

https://stackoverflow.com/questions/479479

20-08-2019
|

Domanda

A volte sono così sfortunato da dover apportare modifiche a oggetti molto vecchi, ~~male~~ non documentato e ~~male~~ non codice progettato.

Spesso ci vuole molto tempo per apportare una semplice modifica perché non c'è molta struttura nel codice esistente e devo davvero leggere molto codice prima di avere un'idea di dove sarebbero le cose.

Ciò che penso sarebbe di grande aiuto in casi come questo è uno strumento che consenta di visualizzare una panoramica del codice e quindi magari anche approfondire per maggiori dettagli.Sospetto che uno strumento del genere sarebbe molto difficile da realizzare, dato che si cerca di trovare una struttura dove ce n'è poca o nessuna.

Immagino che questa non sia davvero una domanda, ma piuttosto una riflessione.Dovrei trasformarla in una domanda - Cosa fanno gli altri per aiutarli a capire il codice degli altri, il bene e il male?

Soluzione

Consiglio vivamente BOUML . È uno strumento di modellazione UML gratuito, che:

è estremamente veloce (lo strumento UML più veloce mai creato, controlla benchmarks ),
ha un solido supporto per l'importazione in C ++,
ha un ottimo supporto all'esportazione SVG, il che è importante, perché la visualizzazione di grafici di grandi dimensioni in formato vettoriale, che si ridimensiona rapidamente ad es. Firefox è molto comodo (puoi passare rapidamente tra & Quot; bird eye & Quot; visualizzazione e visualizzazione dettagli classe),
è completo, sviluppato intensamente (guarda storia dello sviluppo , è difficile credere che progressi così rapidi sono possibili).

Quindi: importa il tuo codice in BOUML e visualizzalo lì, oppure esporta in SVG e visualizzalo in Firefox.

Altri suggerimenti

Hmm, questa è dura, tanto da dire, così poco tempo...

1) Se riesci a eseguire il codice, la vita diventa davvero molto più semplice, i punti di interruzione (soprattutto condizionali) sono tuoi amici.

2) Un approccio da puristi sarebbe quello di scrivere alcuni test unitari, per funzionalità note, quindi eseguire il refactoring per migliorare il codice e la comprensione, quindi ripetere il test.Se le cose si interrompono, crea più test unitari: ripeti finché non sei annoiato/vecchio/spostato in un nuovo progetto

3) ReSharper è bravo a mostrare dove vengono utilizzate le cose, cosa chiama un metodo, ad esempio, è statico ma è un buon inizio e aiuta con il refactoring.

4) Molti eventi .net sono codificati come pubblici e può essere difficile eseguire il debug degli eventi anche nel migliore dei casi.Ricodificali come privati e utilizza una proprietà con aggiungi/rimuovi.È quindi possibile utilizzare il punto di interruzione per vedere cosa è in ascolto su un evento.

A proposito, sto giocando nello spazio .Net e mi piacerebbe uno strumento che mi aiuti a fare questo genere di cose, come Joel, qualcuno là fuori conosce un buon strumento di revisione del codice dinamico?

In passato mi è stato chiesto di diventare proprietario di un codice NASTY - sia funzionante che " play " ;.

La maggior parte dei dilettanti per i quali ho preso il codice aveva appena evoluto il codice per fare ciò di cui aveva bisogno in diverse iterazioni. Era sempre un gigantesco incestuoso casino della biblioteca A che chiamava B, richiamava in A, chiamava C, chiamava B, ecc. Molte volte usavano i thread e non si vedeva una sezione critica.

Ho trovato il modo migliore / unico per ottenere un handle sul codice era iniziare dal punto di ingresso del sistema operativo [main ()] e creare il mio diagramma dello stack di chiamate che mostra l'albero delle chiamate. All'inizio non è necessario costruire un albero completo. Basta seguire le sezioni su cui stai lavorando in ogni fase e avrai una buona padronanza delle cose per poter correre con essa.

Per finire, usa la più grande fetta di albero morto che puoi trovare e una penna. Disporre tutto davanti a te in modo da non dover saltare avanti e indietro su schermi o pagine rende la vita molto più semplice.

EDIT: Si parla molto degli standard di codifica ... faranno apparire il codice scadente coerente con un buon codice (e di solito è più difficile da individuare). Gli standard di codifica non sempre facilitano il mantenimento del codice.

Lo faccio regolarmente. E hanno sviluppato alcuni strumenti e trucchi.

Prova a ottenere una panoramica generale (diagramma a oggetti o altro).
Documenta i tuoi risultati.
Verifica i tuoi presupposti (specialmente per il codice vago).

Il problema è che nella maggior parte delle aziende sei apprezzato per risultato. Ecco perché alcuni programmatori scrivono velocemente codice scadente e passano a un altro progetto. Quindi rimani con la spazzatura e il tuo capo confronta i tuoi lenti progressi con il ragazzo veloce e sporco. (Fortunatamente il mio attuale datore di lavoro è diverso).

In genere utilizzo diagrammi di sequenza UML di vari modi chiave in cui viene utilizzato il componente. Non conosco nessuno strumento in grado di generarli automaticamente, ma molti strumenti UML come BoUML e EA Sparx possono creare classi / operazioni dal codice sorgente che consente di risparmiare un po 'di battitura.

Il testo definitivo su questa situazione è il lavoro efficace di Michael Feathers con il codice legacy. As S. Lott dice di ottenere alcuni unit test per stabilire il comportamento del codice di lagacy. Una volta che hai quelli dentro puoi iniziare a refactoring. Sembra esserci un capitolo di esempio disponibile sul sito web di Mentor.

Vedi Applicazioni Webforms ASP.NET legacy di unit testing per consigli su come ottenere un grip su app legacy tramite unit test.

Esistono molte domande e risposte simili. Ecco la ricerca https://stackoverflow.com/search?q=unit+test+legacy

Il punto è che aggirare l'eredità è probabilmente più semplice se si scrivono test unitari per quell'eredità.

Non ho avuto molta fortuna con gli strumenti per automatizzare la revisione di codice scarsamente documentato / eseguito, perché un programma confuso / mal progettato generalmente si traduce in un modello poco utile. Non è entusiasmante o immediatamente gratificante, ma ho ottenuto i migliori risultati scegliendo un posto e seguendo l'esecuzione del programma riga per riga, documentando e aggiungendo commenti mentre procedo e rifattorando dove applicabile.

un buon IDE (EMACS o Eclipse) potrebbe aiutare in molti casi. Anche su una piattaforma UNIX, ci sono alcuni strumenti per il riferimento incrociato (etags, ctags) o il controllo (lint) o gcc con molte molte opzioni di avviso attivate.

In primo luogo, prima di provare a comprendere una funzione / metodo, lo riformulerei un po 'per adattarlo alle convenzioni di codifica (spazi, parentesi graffe, rientro) e rimuovere la maggior parte dei commenti se sembrano sbagliati.

Quindi refactoring e commenterei le parti che hai capito, e proverei a trovare / grep quelle parti sull'intero albero dei sorgenti e li refactment anche lì.

Nel corso del tempo, ottieni un codice migliore, con cui ti piace lavorare.

Personalmente disegno molto diagrammi e capisco le ossa della struttura.

La moda del giorno (e forse giustamente) mi ha fatto scrivere test unitari per testare le mie affermazioni e creare una rete di sicurezza per le modifiche che apporto al sistema.

Una volta arrivato al punto in cui mi sento abbastanza a mio agio da sapere cosa fa il sistema, mi prenderò cura di correggere i bug nel modo più sano possibile e spero che le mie reti di sicurezza si stiano avvicinando al completamento.

Sono solo io, comunque. ;)

Ho effettivamente utilizzato le funzionalità di refactoring di ReSharper per aiutarmi a ottenere una gestione di un gruppo di progetti che ho ereditato di recente. Quindi, per capire il codice di un altro programmatore molto poco strutturato, non documentato, in realtà comincio a riformattarlo.

Ripulire il codice, rinominare correttamente metodi, classi e spazi dei nomi, estrarre i metodi sono tutti cambiamenti strutturali che possono far luce su ciò che un pezzo di codice dovrebbe fare. Potrebbe sembrare controintuitivo codificare il codice che non si & Quot; conoscere & Quot; ma trut me, ReSharper ti permette davvero di farlo. Prendiamo ad esempio il problema del codice morto delle aringhe rosse. Vedi un metodo in una classe o forse una variabile dal nome strano. Puoi iniziare cercando di cercare gli usi o, ungh, fare una ricerca di testo, ma ReSharper rileverà effettivamente il codice morto e lo colorerà di grigio. Non appena apri un file che vedi in grigio e con le bandiere della barra di scorrimento, ciò che in passato avrebbe confuso le aringhe rosse.

Ci sono dozzine di altri trucchi e probabilmente una serie di altri strumenti che possono fare cose simili ma io sono un drogato di ReSharper.

Saluti.

Conosci il software intimamente dal punto di vista di un utente. Si può imparare molto sulla struttura sottostante studiando e interagendo con le interfacce utente.

Stampe
Lavagne
Un sacco di carta da lettere
Ci sono un sacco di Starbucks

Poter scarabocchiare dappertutto, poverino, è il metodo più utile per me.Di solito mi capita di dire un sacco di "eh, che divertente..." mentre provo a creare diagrammi di base della struttura del codice che alla fine risultano più utili dei diagrammi stessi.Gli strumenti automatizzati sono probabilmente più utili di quanto io creda, ma il valore di trovare quelle parti divertenti supera per me il valore dei diagrammi generati rapidamente.

Per i diagrammi, cerco principalmente dove stanno andando i dati.Da dove entra, dove finisce e cosa attraversa lungo il percorso.Generalmente ciò che accade ai dati sembra dare una buona impressione del layout generale e alcuni elementi a cui tornare se sto riscrivendo.

Quando sto lavorando su un codice legacy, non provo a capire l'intero sistema. Ciò comporterebbe un sovraccarico di complessità e una conseguente esplosione cerebrale.

Piuttosto, prendo una singola funzionalità del sistema e provo a capire completamente come funziona, da un capo all'altro. Generalmente eseguirò il debug nel codice, a partire dal punto nel codice dell'interfaccia utente in cui posso trovare la funzionalità specifica (poiché questa è di solito l'unica cosa che riuscirò a trovare all'inizio). Quindi eseguirò alcune azioni nella GUI e analizzerò il codice fino in fondo nel database e poi eseguirò il backup. Ciò si traduce in genere in una comprensione completa di almeno una caratteristica del sistema e talvolta fornisce informazioni anche su altre parti del sistema.

Una volta compreso quali funzioni vengono chiamate e quali procedure, tabelle e viste memorizzate sono coinvolte, faccio una ricerca attraverso il codice per scoprire quali altre parti dell'applicazione si basano su queste stesse funzioni / processi. È così che scopro se una modifica che farò romperà qualsiasi altra cosa nel sistema.

A volte può anche essere utile tentare di creare diagrammi del database e / o della struttura del codice, ma a volte è così male o così follemente complesso che è meglio ignorare il sistema nel suo insieme e concentrarsi solo sulla parte che devi cambiare.

Il mio grosso problema è che (attualmente) ho sistemi molto grandi da capire in un breve lasso di tempo (peccato per gli sviluppatori di contratti su questo punto) e non ho molta esperienza nel farlo (essendo stato precedentemente fortunato abbastanza per essere quello che progetta da zero.)

Un metodo che uso è quello di cercare di comprendere il significato della denominazione di variabili, metodi, classi, ecc. Ciò è utile perché (si spera sempre più) incorpora una visione di alto livello di un treno di pensiero a livello atomico .

Dico questo perché in genere gli sviluppatori nomineranno i loro elementi (con quello che credono siano) in modo significativo e forniranno informazioni sulla loro funzione prevista. Questo è errato, è vero, se lo sviluppatore ha una comprensione difettosa del proprio programma, la terminologia o (spesso il caso, imho) sta cercando di sembrare intelligente. Quanti sviluppatori hanno visto parole chiave o nomi di classe e solo allora hanno cercato il termine nel dizionario, per la prima volta?

Riguarda gli standard e le regole di codifica utilizzati dalla tua azienda.

se tutti codificano in uno stile diverso, è difficile mantenere un altro codice programmatore ed ecc., se decidi quale standard utilizzerai alcune regole, tutto andrà bene :) Nota: che non devi fare molte regole, perché le persone dovrebbero avere la possibilità di scrivere il codice nello stile che preferiscono, altrimenti potresti essere molto sorpreso.

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow