Best practice sulla gestione della complessità / visualizzazione dei componenti nel tuo software?

Question

Stiamo creando strumenti per estrarre informazioni dal Web. Abbiamo diversi pezzi, come

• Scansiona i dati dal Web
• Estrai informazioni in base a template e amp; regole commerciali
• Analizza i risultati nel database
• Applica normalizzazione e amp; regole di filtro
• Ecc, ecc.

Il problema è risolvere i problemi & amp; avere una buona "immagine di alto livello" di ciò che sta accadendo in ogni fase.

Quali tecniche ti hanno aiutato a comprendere e gestire processi complessi?

• Utilizza strumenti per il flusso di lavoro come Windows Workflow Foundation
• Incapsula funzioni separate in strumenti da riga di comando e amp; utilizzare gli strumenti di scripting per collegarli insieme
• Scrivi un DSL (Domain-Specific Language) per specificare l'ordine in cui le cose dovrebbero accadere a un livello superiore.

Sono solo curioso di sapere come ottenere un handle su un sistema con molti componenti interagenti. Vorremmo documentare / capire come funziona il sistema ad un livello superiore rispetto al tracciamento attraverso il codice sorgente.

Answer 1

Il codice dice cosa succede in ogni fase. L'uso di una DSL sarebbe un vantaggio, ma probabilmente non lo sarebbe se il costo di scrivere il proprio linguaggio di scripting e / o compilatore fosse.

La documentazione di livello superiore non dovrebbe includere dettagli di ciò che accade in ogni fase; dovrebbe fornire una panoramica delle fasi e del modo in cui si relazionano insieme.

Buoni consigli:

• Visualizza le relazioni dello schema del database.
• Usa visio o altri strumenti (come quello che hai menzionato - non l'ho mai usato) per panoramiche di processo (poiché appartiene alla specifica del tuo progetto).
• Assicurati che il tuo codice sia correttamente strutturato / compartimentato / ecc.
• Assicurati di avere una sorta di specifica del progetto (o qualche altra documentazione "generale" che spieghi cosa fa il sistema a livello astratto).

Non consiglierei di costruire strumenti da riga di comando a meno che tu non li abbia effettivamente utilizzati. Non c'è bisogno di mantenere strumenti che non usi. (Non è lo stesso che dire che non può essere utile; ma la maggior parte di ciò che fai sembra più simile a quello che appartiene a una libreria piuttosto che all'esecuzione di processi esterni).

Answer 2

Uso il famoso Graphviz di AT & amp; T, è semplice e funziona bene. È la stessa libreria utilizzata anche da Doxygen.

Anche se fai un piccolo sforzo puoi ottenere dei grafici molto belli.

Dimenticato di menzionarlo, il modo in cui lo uso è il seguente (poiché Graphviz analizza gli script Graphviz), utilizzo un sistema alternativo per registrare gli eventi in formato Graphviz, quindi analizzo il file Log e ottengo un bel grafico.

Answer 3

Trovo una matrice della struttura di dipendenza un modo utile per analizzare la struttura di un'applicazione. Uno strumento come lattix potrebbe essere d'aiuto.

A seconda della piattaforma e della toolchain ci sono molti pacchetti di analisi statiche davvero utili che potrebbero aiutarti a documentare le relazioni tra sottosistemi o componenti dell'applicazione. Per la piattaforma .NET, NDepend è un buon esempio. Ce ne sono molti altri per altre piattaforme però.

Avere una buona progettazione o un modello prima di costruire il sistema è il modo migliore per comprendere il team su come strutturare l'applicazione, ma strumenti come quelli che ho citato possono aiutare a far rispettare le regole dell'architettura e spesso ti daranno informazioni progettare che non è possibile esplorare solo il codice.

Answer 4

Non userei nessuno degli strumenti che hai citato.

Devi disegnare un diagramma di alto livello (mi piacciono la matita e la carta).

Progetterei un sistema con moduli diversi che fanno cose diverse, varrebbe la pena progettarlo in modo da poter avere molte istanze di ogni modulo in esecuzione in parallelo.

Vorrei pensare a usare più code per

• URL da sottoporre a scansione
• Pagine sottoposte a scansione dal Web
• Informazioni estratte basate su template e amp; regole commerciali
• Risultati analizzati
• normalizzato & amp; risultati filtrati

Avresti programmi semplici (probabilmente da riga di comando senza UI) che leggessero i dati dalle code e inserissero i dati in una o più code (Il crawler alimenterebbe entrambi gli " URL da sottoporre a scansione " e " Pagine sottoposte a scansione dal web " ), puoi utilizzare:

• Un crawler web
• Un estrattore di dati
• Un parser
• Un normalizzatore e un filtro

Questi si incastrerebbero tra le code e potresti farne molte copie su PC separati, permettendo così di ridimensionare.

L'ultima coda potrebbe essere inviata a un altro programma che in realtà inserisce tutto in un database per l'uso effettivo.

Answer 5

La mia azienda scrive specifiche funzionali per ciascun componente principale. Ogni specifica segue un formato comune e utilizza vari diagrammi e immagini a seconda dei casi. Le nostre specifiche hanno una parte funzionale e una parte tecnica. La parte funzionale descrive cosa fa il componente ad alto livello (perché, quali obiettivi risolve, cosa non fa, con cosa interagisce, documenti esterni correlati, ecc.). La parte tecnica descrive le classi più importanti nel componente e qualsiasi modello di progettazione di alto livello.

Preferiamo il testo perché è il più versatile e facile da aggiornare. Questo è un grosso problema - non tutti sono esperti (o addirittura decenti) in Visio o Dia, e questo può essere un ostacolo per mantenere aggiornati i documenti. Scriviamo le specifiche su una wiki in modo da poter facilmente collegarci tra ogni specifica (così come le modifiche delle tracce) e consentire una camminata non lineare attraverso il sistema.

Per un argomento dell'autorità, Joel raccomanda le Specifiche funzionali qui e qui .

Answer 6

Il design top down aiuta molto. Un errore che vedo è quello di rendere sacro il design top down. Il tuo progetto di livello superiore deve essere rivisto e aggiornato come qualsiasi altra sezione di codice.

Answer 7

È importante partizionare questi componenti durante il ciclo di vita dello sviluppo del software: tempo di progettazione, tempo di sviluppo, test, rilascio e runtime. Basta disegnare un diagramma non è abbastanza.

Ho scoperto che l'adozione di un'architettura microkernel può davvero aiutare a "dividere e conquistare" questa complessità. L'essenza dell'architettura microkernel è:

• Processi (ogni componente viene eseguito in uno spazio di memoria isolato)
• Thread (ogni componente viene eseguito su un thread separato)
• Comunicazione (i componenti comunicano attraverso un singolo, semplice canale di passaggio messaggi)

Ho scritto un sistema di elaborazione batch abbastanza complesso che suona simile al tuo sistema usando:

Ogni componente esegue il mapping all'eseguibile .NET Le vite eseguibili sono gestite tramite Autosys (tutte sullo stesso computer) La comunicazione avviene tramite TIBCO Rendezvous

Se puoi usare un toolkit che fornisce qualche introspezione di runtime, anche meglio. Ad esempio, Autosys mi consente di vedere quali processi sono in esecuzione, quali errori si sono verificati mentre TIBCO mi consente di ispezionare le code dei messaggi in fase di esecuzione.

Answer 8

Mi piace usare NDepend per decodificare la base di codice .NET complessa. Lo strumento viene fornito con diverse funzionalità di visualizzazione come:

Grafico delle dipendenze:

Matrice delle dipendenze:

Visualizzazione della metrica del codice tramite treemaping: