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 design, cosa cerchi in esso? Diagrammi di classe o diagrammi di spiegamento o diagrammi di sequenza o qualcos'altro?
O vai dritto per il codice? In tal caso, come capisci come interagiscono i diversi livelli?
Risposte:
Comincio con il codice. Eventuali documenti di progettazione separati, se presenti, hanno la probabilità di essere errati o concepiti erroneamente. Quindi, inizio provando a tracciare un semplice flusso attraverso il codice; se è una webapp, potrebbe essere una richiesta o una sequenza di richieste, ad esempio. Una volta che l'ho fatto, ho una specie di scheletro su cui pendere più comprensione. Quindi, potrei tornare indietro e leggere progetti o altra documentazione, ma a quel punto, ho qualcosa di concreto con cui collegarli e con cui convalidarli, in modo da poter rilevare le informazioni di duff. Oppure potrei continuare a leggere il codice, o casi di test, ecc.
Vorrei iniziare a un livello superiore. Se è presente documentazione per l'utente - manuale o guida per l'utente. In caso contrario, dai un'occhiata alle specifiche dei requisiti in modo da avere qualche idea su cosa dovrebbe fare il software. Vorrei piuttosto guardare il design e provare a mapparlo sui file di codice. Speriamo che questi siano strutturati in cartelle in qualche modo ragionevole. Vorrei quindi scegliere una parte del design e andare nei file per seguire il flusso del codice senza impantanarmi troppo nei minimi dettagli.
Comincio installando un sistema di sviluppo. Uso la procedura documentata. Questo fa uscire il gatto dalla borsa su quanto la documentazione è sincronizzata con la realtà.
Mi dice anche quali sono le dipendenze. Questo conta.
Ora che ho una configurazione per sviluppatori (e aggiungo correzioni al documento di installazione con le correzioni), costruisco una versione. Finisco per porre domande durante questa fase.
Ora è stato costruito, faccio l'esercizio introduttivo dal manuale dell'utente. Questo mi dice più o meno cosa fa davvero il sistema.
Ora ho un indizio parziale sul sistema, ho letto i documenti di progettazione, che ora credo in proporzione a quanto i documenti siano stati finora sbagliati.
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 "fix in version 2.0" sono anche suggerimenti.
Quindi si tratta di imparare la veridicità e, come sottolineano le persone, documenti di progettazione separati raramente sono aggiornati o corretti, ma ti dicono cosa la gente stava pensando in un determinato momento. E, naturalmente, quelle persone probabilmente non sono in giro per interrogare.
La mia preferenza è iniziare con la progettazione per ottenere una panoramica del progetto e provare a comprendere 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 installazione dello sviluppatore (controllare l'origine, ottenere il progetto creato, apportare eventuali modifiche alla configurazione) ma non ha senso provare a imparare la struttura di un'applicazione dal suo codice. Questo ti dice solo qual è la struttura, non perché la struttura è o cosa pensano gli altri sviluppatori i punti salienti e negativi dell'architettura. Quelli che impari dai diagrammi della lavagna e chat con gli sviluppatori.
Per un software complesso lo approccerei approssimativamente come se fosse un nuovo progetto di sviluppo. Inizia con le grandi idee: visione, contesto, portata, parti interessate. Leggi la documentazione per l'utente e ottieni un'idea di come viene utilizzato. Ottieni 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 ad alto livello. Parla con i designer se sono ancora in giro. Guarda l'architettura di sistema in diverse prospettive. Da lì, inizia a scavare nella funzionalità principale e guarda un po 'di codice, tornando ai requisiti e al design secondo necessità. Mentre guardi il codice, esegui il software per vederlo in azione. Nel frattempo, compila una documentazione di riepilogo per riferimento futuro: possiedi Cliffs Notes. Esegui la ramificazione fino a quando non hai una buona idea di come tutto funziona e si adatta insieme, ma concentrati sulle parti con cui lavorerai. Ormai hai una comprensione da cima a fondo dell'intero sistema, o almeno delle parti che ti sono applicabili.
Certo, nel mondo reale potresti non avere il tempo di affrontare tutto questo prima di dover iniziare a sporcarti le mani, specialmente nei progetti più grandi. Ma è così che 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 importa. Leggi il codice fino a quando non sei davvero confuso, quindi dai un'occhiata ai documenti di progettazione. In alternativa, 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, fintanto che tieni a mente questi punti, i documenti obsoleti ti aiutano ancora a capire la mente dell'autore ad un certo punto nel passato. Molti dei problemi e delle preoccupazioni di alto livello saranno ancora validi e molto probabilmente sarai in grado di capire più rapidamente come il codice è arrivato dove si trova, se hai anche una foto datata di dove l'autore inizialmente pensava che sarebbe andato partire.
Mentre lavori attraverso il codice e la progettazione, crea i tuoi documenti che descrivono la tua comprensione del codice oggi. Forse questi documenti sono uno o due semplici schizzi, forse sono delle scritture in un wiki, forse sono qualcos'altro. Non renderli troppo complicati: nessun documento di parole di 30 pagine. Abbassa le idee, il che chiarirà notevolmente il tuo modo di pensare.
Dipende dal tipo di applicazione. Se si tratta di un'app incentrata sui dati, di solito inizio con la progettazione del database. Se ha un'interfaccia utente che puoi eseguire (o buoni design dello schermo), questi possono anche darti una buona idea di cosa fa l'app molto rapidamente (sto parlando solo poche ore qui al massimo). Dopo di che inizio 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 racconta l'intento della cosa che si sta guardando.
Se possibile, guardo quindi le note di progettazione e la documentazione per avere un'idea generale di come è stato fatto, il processo di pensiero, lo stile e la 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?
Gli sviluppatori hanno la tendenza a saltare nel codice: "Lascia che ti mostri questo codice". Questo va bene per loro, ma tende a dirottare i miei bisogni - che è capire l'alto livello che dà contesto alle cose di basso livello.
Usa enormi quantità di potenza del cervello per guardare piccoli frammenti di codice, fuori dal contesto completo e capire qualcosa di significativo. Quindi, se possibile, indurre gli sviluppatori a parlare del PRINCIPIO, della struttura, delle unità, dei moduli, qualunque cosa conduca ad un apprezzamento del compito.
Solo allora vale la pena provare a entrare nel codice.
Nel grande schema delle cose, guardare il codice è come guardare una pagina piena di 0 e 1. C'è un significato, ma ci vuole molto tempo per capirlo. Ottenere un assaggio di dove cercare e quali parti sono significative aiuta a restringere lo spazio di ricerca.
Tutto ciò che ha detto - quando non c'è doco, persone e solo codice - non c'è altro da fare che guardare il codice.
In tal caso, normalmente non provo a capirlo con una lettura lenta e profonda, faccio un passaggio veloce, sfoglio la lettura di tutto. A volte si tratta solo di aprire file e sedersi premendo il tasto di scorrimento verso il basso. Puoi ottenere un incredibile apprezzamento di un'immagine grande semplicemente facendo questo. (E in alcuni casi ho persino scaricato file eseguibili e trascinato quelli in cerca di firme e modelli. Questo è stato incredibilmente fruttuoso negli ultimi 20 anni.)
Comincio con i test. Se i test unitari e i test di integrazione sono ben scritti, descrivono i casi d'uso. Se non sono ben scritti o non sono affatto scritti (purtroppo, questo è in gran parte il caso), inizio con i punti di ingresso nel codice e abbino quelli con il design.
Scriverò quindi 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; scrivere test, ripulire il codice, refactoring di grandi (20+ righe) funzioni.
Trovo che la creazione della 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 design a metà (e la maggior parte lo fa), non puoi programmare a metà
qualsiasi progetto sarà semplicemente un'opinione , mentre il codice è il fatto
farò riferimento a documenti secondari solo quando non riesco a capire il ragionamento del codice
leggere il codice è un'abilità essenziale per uno sviluppatore. potresti anche impararlo ora, non vedrai comunque molta documentazione utile durante la tua carriera
Quindi guardo il README dello sviluppatore, TODO e il log delle modifiche. Se non capisco perché il software è stato scritto, come è stato scritto e dove sta andando ... Non lo uso.
Progetta prima, poi codifica, dall'alto verso il basso se lo desideri, quindi capisco il contesto ad ogni livello in cui devo lavorare.
Ma se devo fare una modifica molto specifica, come correggere un report o un calcolo, vado solo a vedere il codice.
Più specificamente, il mio approccio "progettare prima" è questo:
Comincio con il modello di dominio se ce n'è uno, se non ce n'è uno 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).
Descrive "quali oggetti sono gestiti" dall'applicazione.
Quindi cerco il modello del caso d'uso per scoprire "quali processi vengono eseguiti" dall'applicazione, anche se preferisco una mappa dei processi, se presente, che mostra sequenze di processi.
Dopo di ciò dovrei avere una bella foto dell'applicazione e poi posso 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 è capire a fondo come funziona il progetto, guardare il codice, almeno per me, è come guardare un puzzle pezzo per pezzo tranne che con ogni classe che guardi, ne stai aggiungendo un altro pezzo del puzzle. Se il codice è ben strutturato, puoi vedere un modello che si forma dai nomi delle classi senza nemmeno investigare su cosa faccia la classe. In molti casi, puoi ottenere suggerimenti e indizi dal codice che ti aiuterà ulteriormente.
Infine, ottieni un'idea irrinunciabile di ciò che fa il programma, un puzzle completato. 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, ti viene più facile, 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 si riduce alle preferenze.
Dopo aver visto il codice del modulo / punto di applicazione più critico: vedendo il codice, posso verificare la bontà del design.
Esempio:
Devi lavorare nella gestione delle applicazioni di un'app Web sui rapporti finanziari.
Dopo aver letto il codice sul messaggio, l'applicazione di inizio e fine (per probabile blocco in db), il processo principale di creazione dei dati che devono essere riportati ecc. Ecc. (Ad esempio, nella conservazione del gas il processo principale riguarda il calcolo dello stock di gas nell'area di stoccaggio dei clienti con fornitura 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 dalla loro prospettiva. Una volta che riesco a creare un'immagine nella mia mente da loro, ho una rapida occhiata al design tecnico e quindi al codice.
Vado prima con il design e poi con il codice contemporaneamente. È molto importante perché ogni progetto è diverso. È necessario elaborare un piano e un livello elevato di flusso di lavoro del processo dalla A alla Z prima di poter iniziare a lavorare sui codici contemporaneamente. Ogni decisione presa deve essere documentata in modo che gli altri team (o te stesso) che stanno / stanno sviluppando i codici conoscano l'ultimo aggiornamento e ciò che è stato confermato.
Se esiste un buon documento di design di alto livello, lo userò. Deve essere conciso e aggiornato. Se è troppo dettagliato o obsoleto, mi dirigerò verso il codice.
Certo, dipende dal progetto, vero? Un progetto estremamente complesso o sfaccettato è forse meglio affrontato attraverso la documentazione (se la documentazione è abbastanza solida.)
A mio avviso, un singolo modulo semplice o una semplice applicazione sono quasi sempre meglio affrontati a livello di codice.
Non esiste una risposta giusta per ogni situazione!