Come tieni traccia dei grandi progetti?

Il trucco per comprendere una base di codice di grandi dimensioni è non provare a capirlo tutto. Dopo una certa dimensione, non puoi tenere un modello mentale nella tua testa dell'intera faccenda. Si inizia con un punto di ancoraggio che ha senso per qualsiasi compito si debba lavorare prima, quindi si dirama da lì, si apprende solo le parti necessarie e si crede che il resto funzioni come pubblicizzato. È come capire la ricorsione. Se provi a trattenere l'intera pila nella tua testa, il tuo cervello esplode.

Grep, debugger e intellisense sono i tuoi amici qui. Se non sai come una funzione finisce per essere chiamata, imposta un punto di interruzione su di essa e vai verso il basso nella traccia dello stack.

L'altra cosa da notare è che le 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. Fai domande come: "Devo aggiungere un nuovo fornitore di servizi di pagamento, dove devo cercare il codice?" Concentrati solo su questo compito invece di cercare di capire l'intero codice base e, pezzo per pezzo, la tua familiarità aumenterà.

Non esiste una scorciatoia. 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 che seguono all'incirca una nuova base di codice:

1. Comprendi cosa fa da un punto di vista dell'utente. Essere in grado di utilizzare effettivamente l'applicazione come un utente esperto. Capire come lavorano i veri utenti finali. Questo potrebbe richiedere di stare con loro fino a quando non avrai una solida comprensione di quello che fanno.

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

3. Ulteriori informazioni su qualsiasi framework tu stia utilizzando. Come minimo, dovresti essere in grado di creare un "mondo ciao" o un'altra semplice applicazione con quella struttura prima di immergerti nell'applicazione di produzione.

4. Affronta l'intero processo di distribuzione (il modo migliore è farlo mentre gli sviluppatori originali ti stanno tenendo la mano). Se non puoi prendere l'attuale base di codice e crearlo e distribuirlo attraverso un ambiente di test / validazione / prod, sei brindato. Anche il più piccolo cambiamento richiederà un salto attraverso tutti gli schieramenti di implementazione, quindi perché non ottenere subito questa parte? In tal modo, verrai introdotto su tutti i server, i database, i servizi e gli script adorabili utilizzati dall'app: saprai "dove vive".

5. Prendi confidenza con i test funzionali (se ce ne sono). Come fai a sapere se la cosa funziona correttamente? Che cosa devono fare le operazioni per la cura e l'alimentazione dell'applicazione?

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

---- Notate che fino a qui, non ho nemmeno menzionato guardando da vicino il codice base. C'è A LOT che puoi conoscere un grande progetto senza nemmeno guardare il codice. A un certo punto, ovviamente, devi familiarizzare con il codice. Ecco cosa mi aiuta:

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

8. Se hai una suite di test unitari, osservarli da vicino dovrebbe fornire una finestra sul funzionamento interno dell'applicazione. Questi saranno anche il primo posto in cui cercare i bug che potresti aver introdotto durante le modifiche.

9. I segnalibri IDE hanno un valore inestimabile per la codifica degli hot spot nella base di codice. Essere in grado di passare rapidamente attraverso di essi promuoverà la comprensione.

10. La lettura di segnalazioni di bug recenti e le loro risoluzioni sono utili anche per la comprensione degli hot-spot e ti aiuteranno ad arrivare rapidamente alle parti più rilevanti del codebase.

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 lo faccio anche per comportamento dinamico per allineare le interazioni tra collaboratori, ma non lo faccio spesso quello .

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

In realtà comincerò a farlo durante la 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) Identifica i servizi comuni: registrazione, gestione delle eccezioni, MVC, connessione al database, controllo, visualizzazione (generazione della pagina) poiché queste sono le parti in cui useremo di più.

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

d) Cerca di apportare alcune modifiche e vedere come vengono fuori. Questo è il passo più grande perché finché non inizi ad apportare modifiche il codice è ancora una scatola nera ....

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

Il mio pensiero è che dovresti leggere la documentazione. So che gli hacker amano dirvi "il codice è la documentazione" e usarlo come scusa per non scrivere alcuna documentazione, ma sono sbagliati. Guarda il kernel di Linux, un enorme progetto software di milioni di righe di codice: non penso che nessuno possa davvero entrare in campo senza aver letto un libro e averlo semplicemente raccolto. Se il codice con cui stai lavorando non è documentato (o ben commentato se è un progetto più piccolo) allora probabilmente non è un buon codice.

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

Scopri l'interfaccia di una piccola unità su cui stai lavorando e registrala per riferimento futuro. Nel tempo cucirai insieme la maggior parte di come funziona. Trova ciò che fa il tuo programma e traccia come scorre quel messaggio. Ad esempio, se il tuo sistema riceve un messaggio di rete in ingresso e invia un messaggio di output, traccia come il messaggio scorre attraverso il sistema, senza preoccuparti di tutti i dettagli, basta vedere 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 singolo modello composto da più sub-modelli, ciascuno composto da pacchetti che sono composti da classificatori, ecc ... Lavorare a più livelli di progetto mi permette anche di rintracciare ogni classificatore e chiamata di metodo a livelli multiproject. Intendo dire che lo stesso metodo può chiamare un classificatore nel progetto A e un altro classificatore nel progetto B. L'unico modo per vedere la struttura completa del progetto è invertirne entrambi allo stesso tempo. Non ho tempo per creare diagrammi componenti e le informazioni non sono veramente accurate. Preferisco chiedere al computer di invertire il progetto completo per me. Faccio un reverse ad ogni iterazione con il team e tutti i miei diagrammi sono immediatamente aggiornati. Il reverse engineering è incrementale e utilizza la mappatura degli ID Java a UML. Intendo dire che ogni elemento java è mappato su un elemento MOF unico e unico che rimane lo stesso durante tutta la vita del progetto, anche se refactored. Ciò non dà più limiti alla modellazione UML e consente la modellazione di progetti molto grandi e complessi. Per vostra informazione lavoro con un progetto che ha più di 5 000 000 linee di codice OOP. Tutti i miei progetti sono invertiti correttamente e la navigazione grafica è possibile

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