Soluzione per l'ingombro del codice in crescita

1

Ho questo cono di cui devo occuparmi. Abbiamo questa applicazione già abbastanza grande che lo scopo principale può essere classificato in 2 funzioni principali:

  • Dati principali (si occupa di relazioni dati piuttosto complesse e analisi dei dati).
  • Presentazione / visualizzazione dei dati (questo è il pezzo che continua a crescere, i motivi per venire dopo.)

Questa informazione presentata all'utente viene eseguita in tutti i modi imprevedibili. Non c'è davvero alcun modo per automatizzare o prevedere ciò che gli utenti troveranno la prossima volta che richiederanno una nuova visualizzazione dei dati. Attualmente, il codice specializzato viene creato come parte della soluzione principale per ogni visualizzazione richiesta. Ciò è andato avanti per anni, e abbiamo escogitato modi per standardizzare e classificare ciò che è comune e ripetitivo, tuttavia il codice continua a crescere e ad aumentare la complessità crescente e a complicare i test automatizzati (fino a 600 visualizzazioni). Una caratteristica importante di questa visualizzazione è che sono utili solo per un po ', dopo che sono stati utilizzati diventano monouso. Non possiamo davvero eliminarli in circa un mese dopo che sono stati usati. Ma nel frattempo vogliamo tenerli in giro per scopi di supporto e come riferimento per i pezzi futuri.

La domanda  c'è un modo per mantenerlo?

Qualcuno ha raccomandato di usare la finestra mobile e di containerizzare tutte le visualizzazioni di dati individuali (viste e tutto il codice direttamente accoppiato), ma mi sembra eccessivo e non risolve il problema del codice in continua crescita.

Il progetto è un nucleo MVC .Net

Qualche idea o esperienza precedente che ha funzionato?

Grazie!

    
posta Chepech 31.10.2017 - 07:39
fonte

2 risposte

2

Senza la conoscenza del tuo dominio, sarebbe difficile dirlo. Tuttavia, mi capita di lavorare su qualcosa di simile.

Sembra che il tuo vero problema sia la scelta dell'infrastruttura.

A causa della loro natura, le visualizzazioni sono limitate poiché esiste un set predefinito di elementi dell'interfaccia utente che è possibile visualizzare. Quindi, le tue visualizzazioni possono essere modellate come una composizione di elementi.

Quindi, invece di codificare le visualizzazioni, memorizzare i dati su come sono composti in un database di documenti. Quindi, semplicemente renderlo su richiesta. Raccomando vivamente React che è naturalmente attrezzato per questo compito.

    
risposta data 31.10.2017 - 08:52
fonte
1

Currently, specialized code is build as part of the main solution for every visualization requested

Questa è la radice del tuo problema. Scrivere report / visualizzazioni una tantum è di solito il punto di partenza per le organizzazioni. Ovviamente hai superato questa fase con 600 rapporti personalizzati.

Ti consiglio di investire in uno strumento di visualizzazione. Ci sono molti là fuori . Ho usato JasperReports , e anche se l'esperienza con esso non era senza problemi, era ancora molto meglio della codifica visualizzazioni personalizzate.

There is really no way to automate or predict what the users will come up with next time they request a new data visualization

Molti di questi strumenti sono dotati di soluzioni self-service che consentono agli utenti di creare le proprie visualizzazioni personalizzate utilizzando query SQL o dati preconfezionati. Per qualsiasi esigenza speciale dei tuoi clienti, puoi adottare un approccio rigido e solo consentire loro di utilizzare ciò che è disponibile o aggiungere funzionalità al tuo strumento che saranno disponibili per qualsiasi altro utente che ne avrà bisogno in futuro. È necessario un modo sistematico e ripetibile per creare report senza coinvolgere codice e test. Una volta sul posto dovrebbe pagare per sé.

    
risposta data 01.11.2017 - 02:05
fonte

Leggi altre domande sui tag