Come tenere traccia di grandi progetti?

Quando ho a che fare con un progetto che ha molti file diversi, mi sembra sempre di perdere traccia di come le parti interagiscono tra loro. Non ho mai avuto grossi problemi a comprendere isolatamente i componenti più piccoli, ma man mano che la complessità del progetto aumenta, mi trovo incapace di costruire mentalmente una comprensione di ciò che sta accadendo. Lo noto soprattutto con i progetti OOP, poiché aumenta il numero di metodi e file sorgente.

Il mio background: sono un programmatore web autodidatta. Mi sono occupato principalmente di Python per script veloci e sporchi, ma ho anche realizzato alcuni progetti base di django . Mi piacciono i framework web come il pallone , perché nella semplicità di un layout a file singolo, posso facilmente tenere traccia (principalmente) di ciò che sta succedendo.

Ora mi trovo in una situazione in cui ho bisogno di interagire con un grande progetto PHP di Zend Framework che qualcun altro ha sviluppato, e sono sopraffatto dal tentativo di capire il codice distribuito su numerosi file.

Quali tecniche e processi hai trovato utili per comprendere una base di codice di grandi dimensioni che qualcun altro ha sviluppato? C'è qualche diagramma particolare che trovi ti aiuta a cogliere l'immagine più grande?

Il trucco per comprendere una base di codice di grandi dimensioni è quello di non cercare di capirlo tutto. Dopo una certa dimensione, non puoi tenere un modello mentale nella tua testa dell'intera cosa. Inizi con un punto di ancoraggio che ha senso per qualsiasi attività su cui devi prima lavorare, quindi prosegui da lì, imparando solo le parti di cui hai bisogno e fidandoti che il resto funzioni come pubblicizzato. È proprio come comprendere la ricorsione. Se provi a tenere l'intero stack nella tua testa il tuo cervello esplode.

Grep, debugger e intellisense sono i tuoi amici qui. Se non sai come finisce per essere chiamata una funzione, imposta un punto di interruzione su di essa e procedi lungo la traccia dello stack.

L'altra cosa da notare è che grandi basi di codice non spuntano dal nulla. Più è grande, più programmatori ci sono con esperienza, quindi chiedi loro da dove iniziare, ma sii specifico. Poni domande del tipo "Devo aggiungere un nuovo fornitore di pagamenti. Dove dovrei cercare il codice?" Concentrati solo su quel compito invece di cercare di comprendere l'intera base di codice e, pezzo per pezzo, la tua familiarità crescerà.

Non ci sono scorciatoie. Devi solo soffrire per questo.

Per rispondere alla tua domanda su come ottenere diagrammi, doxygen è ciò che desideri. AFAIK funziona con PHP.

Più in generale, passo attraverso le fasi approssimativamente seguenti quando incontro una nuova base di codice:

1. Comprendi cosa fa dal punto di vista dell'utente. Essere in grado di utilizzare l'applicazione da soli come un utente esperto. Comprendi come i veri utenti finali lavorano con esso. Ciò potrebbe richiedere sedersi con loro fino a quando non si ottiene una solida comprensione di ciò che fanno.

2. Comunicare con gli sviluppatori originali, se possibile. All'inizio, avrai domande architettoniche stimolate dall'esperienza dell'utente finale. Successivamente, avrai domande di implementazione su casi limite e dettagli. Essere in grado di ottenere risposte dagli sviluppatori aiuterà molto più di qualsiasi commento o documentazione (che nella migliore delle ipotesi è incompleta e spesso fuorviante o del tutto assente).

3. Scopri quale framework stai usando. Come minimo, dovresti essere in grado di creare un "ciao mondo" o un'altra semplice applicazione con quel framework prima di immergerti nell'applicazione di produzione.

4. Ottieni un controllo su tutto il processo di distribuzione (meglio se gli sviluppatori originali ti tengono per mano). Se non riesci a prendere la base di codice corrente, costruirla e distribuirla attraverso un ambiente test / validation / prod, sei brindisi. Anche il più piccolo cambiamento richiederà di saltare attraverso tutti i cerchi della distribuzione, quindi perché non ottenere subito questa parte? In tal modo, verrai introdotto a tutti i server, database, servizi e script adorabili utilizzati dall'app: saprai "dove vive".

5. Scopri i test funzionali (se presenti). Come fai a sapere se la cosa funziona correttamente? Cosa devono fare le persone per la cura e l'alimentazione dell'applicazione?

6. Comprendi i registri dell'app. Anche se non ho mai lavorato con PHP, farò una supposizione e dirò che qualsiasi applicazione PHP seria avrà qualche tipo di registrazione. Se capisci i log, avrai un buon punto di partenza quando arriva il momento di problemi di debug.

---- Nota che fino a qui non ho nemmeno menzionato guardando da vicino la base di codice. C'è MOLTO che puoi imparare su un grande progetto senza nemmeno guardare il codice. Ad un certo punto, ovviamente, devi familiarizzare con il codice. Ecco cosa mi aiuta:

7. Per i diagrammi, doxygen è uno strumento eccellente che genererà diagrammi di chiamata e altre relazioni per te. Capita di avere la capacità di PHP! Se non hai provato doxygen, devi assolutamente provarlo. Anche se non posso garantire quanto sia comprensibile il codice all'interno di un framework, ma potrebbe aiutare. Gli sviluppatori originali sono spesso scioccati da ciò che vedono quando vengono presentati documenti del loro codice generati da doxygen. La buona notizia è che aiuta davvero a correre la loro memoria e ad aiutarti meglio.

8. Se disponi di una serie di test unitari, esaminandoli da vicino dovresti fornire una finestra sul funzionamento interno dell'applicazione. Questi saranno anche il primo posto in cui cercare i bug che potresti aver introdotto mentre apporta le modifiche.

9. I segnalibri IDE sono preziosi per etichettare i punti attivi nella base di codice. Essere in grado di alternarli rapidamente promuoverà la comprensione.

10. La lettura di segnalazioni di errori recenti e le relative risoluzioni sono utili anche per comprendere gli hot-spot e ti aiuteranno ad aggiornarti sulle parti più rilevanti della base di codice.

Come richiesto, ecco il mio commento come risposta.

Quando lavoro con il codice di altre persone, tendo a creare o se possibile generare diagrammi di classe UML per darmi una panoramica della struttura statica. Il diagramma visivo mi aiuta soprattutto quando devo tornare più tardi e ho già dimenticato il contesto di una classe. A volte faccio per comportamento dinamico e per allineare le interazioni tra collaborateurs, ma io non lo faccio , che spesso.

Se la base di codice contiene test (integrazione o unità), a volte vale anche la pena verificarli.

In realtà inizierò a farlo nel corso di questa settimana in cui un nuovo cliente ha bisogno di miglioramenti per un prodotto lasciato da un altro sviluppatore. Di seguito sono riportati i passaggi da seguire:

a) Identificare il framework di programmazione utilizzato, che aiuta a sapere come scorre l'applicazione.

b) Identificare i servizi comuni: registrazione, gestione delle eccezioni, MVC, connessione al database, controllo, visualizzazione (generazione della pagina) poiché queste sono le parti in cui utilizzeremo di più.

c) Esegui i flussi di utenti comuni (nell'applicazione), quindi prova ad allinearli a come è strutturato il codice

d) Prova ad apportare alcune modifiche e guarda come vengono fuori. Questo è il passo più grande perché fino a quando non inizi a fare modifiche il codice è ancora una casella nera ....

Ti farò sapere quali altre idee avrò nel corso delle prossime due settimane

Il mio pensiero è che dovresti leggere la documentazione. So che gli hacker adorano dirti "il codice è la documentazione" e usarlo come scusa per non scrivere alcuna documentazione, ma si sbagliano. Guarda il kernel di Linux, un enorme progetto software con molti milioni di righe di codice: non credo che qualcuno potrebbe davvero tornare in auge senza aver letto un libro e semplicemente prenderlo. Se il codice con cui stai lavorando non è documentato (o ben commentato se un progetto più piccolo), probabilmente non è un buon codice.

Se stai lavorando con qualcosa di veramente grande senza documentazione (ci sono stato anch'io, è approssimativo!), Quello che ho trovato che aiuta è cercare di isolare la parte su cui stai lavorando. In quella parte del codice, scopri come i dati / eventi / messaggi / interazioni passano dentro e fuori da quell'unità. In altre parole, retroingegnerizzare l'interfaccia. Scrivilo. La prossima volta che lavori su un'altra unità (bonus se parla con quello con cui hai lavorato per primo), fai la stessa cosa. Conserva tutta la tua documentazione. Dopo alcuni mesi avrai una bella foto di come scorre la cosa.

Scopri l'interfaccia di una piccola unità su cui stai lavorando e registrala per riferimento futuro. Nel tempo ricucirai la maggior parte di come funziona. Scopri cosa fa il tuo programma e traccia come scorre quel messaggio. Ad esempio, se il tuo sistema accetta un messaggio di rete di input e invia un messaggio di output, traccia il modo in cui quel messaggio scorre attraverso il sistema, senza preoccuparti di tutti i dettagli, vedi solo dove va.

Quello che faccio è creare un singolo modello UML da tutti i file che sono stati invertiti da Java a UML. Questo approccio significa che il modello non è più solo una visione astratta del progetto, ma il progetto stesso è interamente mappato su MOF e quindi su UML.

Quello che ottengo è un grande modello singolo composto da più modelli secondari ciascuno composto da pacchetti composti da classificatori ecc. Lavorare a livello di più progetti mi permette anche di tracciare ogni classificatore e chiamate di metodo a livelli di multiprogetto. Voglio dire che lo stesso metodo può chiamare un classificatore nel progetto A e un altro classificatore nel progetto B. L'unico modo per vedere l'intera struttura del progetto è di invertire entrambi contemporaneamente. Non ho tempo per creare diagrammi di componenti e le informazioni non sono molto precise. Preferisco chiedere al computer di invertire il progetto completo per me. Faccio il contrario ad ogni iterazione con il team e tutti i miei diagrammi vengono immediatamente aggiornati. Il reverse engineering è incrementale e utilizza la mappatura degli ID da Java a UML. Voglio dire che ogni elemento java è mappato su un singolo e unico elemento MOF che rimane lo stesso per tutta la durata del progetto anche se sottoposto a refactoring. In questo modo non si ha più limite alla modellazione UML e si consente la modellazione di progetti molto grandi e complessi. Per tua informazione, lavoro con un progetto che ha più di 5.000.000 di righe di codice OOP. Tutti i miei progetti sono invertiti correttamente ed è possibile la navigazione grafica

Uso solo diagrammi di classe perché dal mio modello UML posso creare tutte le viste necessarie che sono sempre aggiornate. Posso anche modellare progetti molto complessi.