Se ti è appena stato presentato un nuovo progetto, qual è la prima cosa che cerchi per avere un'idea di come funziona?
Cerchi prima il design? Se c'è un disegno, cosa cerchi in esso? Diagrammi di classe o diagrammi di implementazione o diagrammi di sequenza o qualcos'altro?
O vai dritto per il codice? In tal caso, come fai a capire come interagiscono i diversi livelli?
Comincio con il codice. I documenti di design separati, se ce ne sono, hanno la stessa probabilità di essere errati o mal concepiti come no. Quindi, inizio cercando di tracciare un flusso semplice attraverso il codice; se è una webapp, potrebbe essere una richiesta o una sequenza di richieste, per esempio. Una volta che l'ho fatto, ho una specie di scheletro su cui appendere più comprensione. Quindi, potrei tornare indietro e leggere disegni o altra documentazione, ma a quel punto, ho qualcosa di concreto con cui collegarli e convalidarli, così posso rilevare le informazioni su Duff. Oppure potrei continuare a leggere codice, o casi di test, ecc.
Vorrei iniziare a un livello più alto. Se esiste una documentazione relativa all'utente - manuale o guida dell'utente. In caso contrario, date un'occhiata alle specifiche dei requisiti in modo da avere un'idea di cosa dovrebbe fare il software. Guarderei il design e cerco di mapparlo sui file di codice. Si spera che questi siano strutturati in cartelle in qualche modo ragionevole. Quindi selezionerei parte del disegno e andrei nei file per seguire il flusso del codice senza cadere troppo nei dettagli.
Inizio impostando un sistema per sviluppatori. Io uso la procedura documentata. Questo lascia il gatto fuori dal sacco su quanto la documentazione sia in sincronia con la realtà.
Mi dice anche quali sono le dipendenze. Questo è importante.
Ora che ho una configurazione per gli sviluppatori, (e registro il documento di installazione con le correzioni mentre procedo) costruisco una versione. Finisco per fare domande in tutta questa fase.
Ora è stato realizzato, eseguo l'esercizio introduttivo dal manuale dell'utente. Questo mi dice approssimativamente cosa fa veramente il sistema.
Ora ho un indizio parziale sul sistema, ho letto i documenti di progettazione, che ora ritengo in proporzione a quanto errati sono stati i documenti finora.
Una volta arrivata alla documentazione comportamentale effettiva, posso iniziare a esaminare il codice e vedere cosa c'è davvero. Non si allineano mai, ma ora so quanto credere.
Quindi guardo l'output IDE per i commenti "todo" e "fixme". Cose come "correzione nella versione 2.0" sono anche tip-off.
Quindi si tratta di imparare la veridicità e, come le persone sottolineano, i documenti di design separati sono raramente aggiornati o corretti, ma ti dice cosa pensavano le persone in un determinato momento. E, naturalmente, queste persone probabilmente non sono in giro per interrogare.
La mia preferenza è iniziare con il design per ottenere una panoramica del progetto e provare a capire alcune delle sue caratteristiche e / o strutture chiave prima di approfondire i dettagli.
Sempre il design. Con il codice vale la pena passare attraverso le fasi di configurazione dello sviluppatore (controllare la fonte, realizzare il progetto, apportare le modifiche necessarie alla configurazione), ma non ha senso cercare di imparare la struttura di un'applicazione dal suo codice. Questo ti dice solo che struttura è, non perché la struttura è o ciò che gli altri sviluppatori pensano che i punti salienti e i punti critici siano dell'architettura. Quelli che impari dai diagrammi della lavagna e dalle chat con gli sviluppatori.
Per un software complesso, mi piacerebbe affrontarlo approssimativamente come se fosse un nuovo progetto di sviluppo. Inizia con le grandi idee: visione, contesto, ambito, stakeholder. Leggi alcuni documenti utente e fatti un'idea di come viene utilizzato. Ottenere una formazione utente con il software, se possibile (o applicabile). Quindi inizia a esaminare i requisiti e la documentazione di progettazione per avere un'idea di come funziona a un livello elevato. Parla con i designer se sono ancora in giro. Guarda l'architettura del sistema in diverse prospettive. Da lì, iniziare a scavare nella funzionalità di base e guardare un po 'di codice, tornando ai requisiti e alla progettazione secondo necessità. Mentre guardi il codice, esegui il software per vederlo in azione. Per tutto il tempo, compila alcuni documenti di riepilogo per riferimenti futuri, possiedi Cliffs Notes. Esci fino a quando non hai una buona idea di come tutto funzioni e combaci, ma concentrati sulle parti con cui lavorerai. Ormai hai una comprensione da cima a fondo dell'intero sistema, o almeno delle parti che sono applicabili a te.
Naturalmente, nel mondo reale potresti non avere il tempo di esaminare tutto questo prima di dover iniziare a sporcarti le mani, specialmente sui progetti più grandi. Ma questo è come lo farei se dipendesse da me.
Dovresti lavorare avanti e indietro tra il codice stesso e tutti i documenti di progettazione.
Puoi iniziare dal codice o dal design e non ha molta importanza. Leggi il codice finché non ti senti bene e veramente confuso, quindi dai un'occhiata ai documenti di progettazione. Oppure leggi i documenti di progettazione per ottenere un'immagine di alto livello, quindi guarda il codice per vedere come appare. Ripeti quasi indefinitamente finché lavori con il codice.
Tieni presente che i documenti di progettazione sono quasi sempre obsoleti e non corretti in molti modi. Tuttavia, se tieni a mente questi punti, i documenti obsoleti ti aiutano ancora a capire la mente dell'autore in qualche momento del passato. Molti dei problemi e dei problemi di alto livello saranno ancora validi e molto probabilmente sarai in grado di capire più rapidamente come il codice è arrivato dove è, se hai anche una foto datata di dove l'autore pensava originariamente stesse andando andare.
Mentre lavori attraverso il codice e la progettazione, crea i tuoi documenti che descrivono la tua comprensione del codice oggi. Forse questi documenti sono un semplice schizzo o due, forse sono scritti in un wiki, forse sono qualcos'altro. Non renderli troppo complicati: niente documenti di 30 pagine. Abbassa le tue idee, il che chiarirà molto il tuo modo di pensare.
Dipende dal tipo di applicazione. Se si tratta di un'app data-centric, di solito inizio con la progettazione del database. Se ha un'interfaccia utente che puoi eseguire (o una buona progettazione dello schermo), quelli possono anche darti una buona idea di cosa faccia l'applicazione molto velocemente (sto parlando solo di poche ore qui al massimo). Dopo di ciò, inizierò a scavare nel codice e avrà più senso perché so cosa sta facendo l'applicazione.
Comincio con la documentazione di progettazione. In particolare, la specifica - che indica l'intento della cosa che viene guardata.
Se possibile, guardo quindi alle note di progettazione e alla documentazione per avere un sapore generale di come è stato fatto, del processo di pensiero, dello stile e della natura delle persone interessate.
Se possibile, allora parlo con le persone che ci hanno lavorato - che cosa fa? Come? Perché? Dove sono sepolti i corpi?
C'è una tendenza tra gli sviluppatori a saltare nel codice: "Lascia che ti mostri questo codice". Questo va bene per loro, ma tende a dirottare le mie esigenze - il che è capire l'alto livello che dà un contesto alle cose di basso livello.
Usa una grande quantità di energia cerebrale per guardare piccoli pezzi di codice, fuori dal contesto completo e capire qualsiasi cosa significhi. Quindi, se possibile, convincere gli sviluppatori a parlare del PRINCIPIO, della struttura, delle unità, dei moduli, qualunque cosa porti a un apprezzamento del compito.
Solo allora vale la pena provare ad entrare nel codice.
Nel grande schema di cose, osservare il codice è come guardare una pagina piena di 0 e di 1. C'è un significato ma ci vuole molto tempo per capirlo. Ottenere un assaggio di dove guardare e quali parti sono significative aiuta a restringere lo spazio di ricerca.
Tutto ciò che ho detto - quando non ci sono documenti, persone e solo codice - allora non c'è niente da fare se non quello di guardare il codice.
In questo caso, di solito non cerco di capirlo da una lenta lettura profonda, faccio un passaggio veloce, sfoglio leggendo su tutto. A volte si tratta solo di file aperti e si siedono premendo il tasto pagina-giù. È possibile ottenere un incredibile apprezzamento di una grande immagine solo facendo questo. (E in alcuni casi eseguo anche il dump di file eseguibili e li scaricano, cercando firme e pattern. Questo è stato incredibilmente fruttuoso negli ultimi 20 anni dispari.)
Comincio con i test. Se i test delle unità e i test di integrazione sono ben scritti, descrivono i casi d'uso. Se non sono scritti bene, o non scritti affatto (purtroppo, questo è in gran parte il caso), inizio con i punti di ingresso nel codice e corrispondono a quelli con il design.
Quindi scriverò dei test per ogni caso d'uso, scoperto dall'albero che troverai dopo aver esaminato i punti di ingresso, per sondare il codice e usare le utilità di copertura del codice per vedere cosa mi manca. Questi test mi dicono esattamente come funziona il codice.
Cerco sempre di aggiungere valore a qualcosa che guardo; scrittura di test, pulizia del codice, refactoring di grandi funzioni (oltre 20 righe).
Trovo che la creazione di documentazione da sola non aggiunga alcun valore reale al codice poiché non interagisce mai con il codice.
bene, qual è il "design"? un README? un diagramma uml? puoi fare un documento di progettazione a metà (e quasi tutto), non puoi codificare a metà strada
qualsiasi progetto è semplicemente un parere , mentre il codice è fact
Mi riferirò solo ai documenti secondari quando non riesco a capire il ragionamento del codice
il codice di lettura è un'abilità essenziale per uno sviluppatore. potresti anche impararlo ora, non vedrai comunque molta documentazione utile durante la tua carriera
Poi guardo README, TODO e Changelog dello sviluppatore. Se non capisco perché il software è stato scritto, come è stato scritto e dove sta andando ... Io non lo uso.
Disegna prima, poi codifica, dall'alto in basso se lo desideri, quindi comprendo il contesto a ogni livello che devo lavorare.
Ma se devo fare un cambiamento molto specifico, come la correzione di un rapporto o un calcolo, vado semplicemente a dare un'occhiata al codice.
Più specificamente, il mio approccio "design first" è questo:
Comincio con il modello de domain se ce n'è uno, se non ce n'è nessuno ne costruisco almeno uno di base (un buon punto di partenza è il modello di dati). Definisce il "glosary" dell'applicazione e la relazione tra gli oggetti (classi).
Immagina "quali oggetti sono gestiti" dall'applicazione.
Quindi cerco il modello del caso d'uso per scoprire "quali processi sono fatti" dall'applicazione, anche se preferisco una mappa dei processi se è una, che mostra sequenze di processi.
Dopo avrò una bella immagine dell'applicazione e poi potrò andare a progettare la modifica.
A proposito, la risposta sopra è nel contesto delle applicazioni aziendali.
Il codice non mente. Certamente una buona idea per avere una panoramica del progetto prima di capire cosa fa. Tuttavia, se il tuo compito è quello di ottenere una comprensione dettagliata di come funziona il progetto, guardare il codice, almeno per me, è come guardare un puzzle pezzo per pezzo eccetto che con ogni classe che guardi, stai aggiungendo un altro pezzo del puzzle. Se il codice è ben strutturato, puoi vedere un pattern che si forma dai nomi delle classi senza nemmeno indagare su cosa fa la classe. In molti casi, puoi ottenere suggerimenti e indizi dal codice che ti aiuterà ulteriormente.
Finalmente, ottieni ciò che è un'idea irrequabile di ciò che fa il programma, un puzzle completo. La documentazione può essere incompleta o imprecisa, ma il codice non mente mai. Tutto ciò che puoi fare senza capire cosa fa ogni singolo metodo. Non tutti possono conoscere un progetto in questo modo, ma se lo fai spesso, è più facile per te, per non parlare del fatto che puoi ottenere l'essenza di un'applicazione di medie dimensioni in un paio d'ore di studio. Anche se suppongo che tutto dipenda dalla preferenza.
Dopo aver visto il codice del modulo / punto di applicazione più critico: vedere il codice, posso farlo per verificare la bontà del design.
Esempio:
Devi lavorare nella gestione delle applicazioni di un'app web sui rapporti finanziari.
Dopo aver letto il codice relativo al messaggio, l'applicazione iniziale e finale (per probabile blocco in db), il processo principale di creazione dei dati che devono essere segnalati ecc. ecc. (ad esempio, nella memoria del gas il processo principale riguarda il calcolo dello stock di gas nell'area di stoccaggio dei clienti con alimentazione e iniezione, il processo secondario è la fatturazione su questi dati precedentemente calcolati)
Né codice né design. Mi piace parlare con le parti interessate e gli utenti finali e scoprire come funziona dal loro punto di vista. Una volta che posso creare un'immagine nella mia mente da loro, ho una rapida occhiata al design tecnico e poi al codice.
Vado prima con il design e poi con il codice contemporaneamente. È molto importante perché ogni progetto è diverso. Prima di iniziare a lavorare sui codici in modo concorrente, è necessario presentare un piano e un alto livello di flusso di lavoro dei processi dalla A alla Z. Ogni decisione presa deve essere documentata in modo che altri team (o te stesso) che stanno / stanno sviluppando i codici conosceranno l'ultimo aggiornamento e ciò che è stato confermato.
Se c'è un buon documento di progettazione di alto livello, lo userò. Deve essere conciso e aggiornato. Se è troppo prolisso o obsoleto, mi occuperò del codice.
Ovviamente, dipende dal progetto, vero? Un progetto estremamente complesso o sfaccettato è forse meglio affrontato attraverso la documentazione (se la documentazione è abbastanza solida).
Un semplice modulo semplice o semplice applicazione è, a mio parere, quasi sempre meglio affrontato a livello di codice.
Non esiste una risposta giusta per ogni situazione!
Leggi altre domande sui tag design architecture