Come scrivere software altamente mutevole e altamente complesso? [chiuso]

Question

Come scrivere software altamente mutevole e altamente complesso? [chiuso]

#1 da (6 voti)
#2 da (1 voti)

1

So che domande come questa sono già state fatte prima. Ma nessuno di loro mi ha risposto veramente.

Come mantenere un prodotto software grande e complesso mantenibile negli anni?
Come organizzi un software altamente personalizzato?
...

Stiamo lavorando su un software che ha un sacco di regole e condizioni. Inoltre, tali regole cambiano frequentemente.

Finora abbiamo utilizzato molti design e tecniche per far fronte ai requisiti e implementarli. Per essere più specifici, concentriamoci sui seguenti esempi:

Utilizzo di opzioni configurabili, in modo che i valori possano essere modificati facilmente dagli uomini d'affari, come l'ammontare del debito che un cliente può subire.
Problema : Presto ci saranno centinaia di configurabili opzioni, e persino nominarli diventa un incubo, figuriamoci gestirli, cambiarli, rintracciarli nel codice, ecc.
Utilizzo di piccoli file di progetto satellite come additivi del motore principale (qualcosa come flusso di lavoro estendibile), in modo che le nuove regole possano essere aggiunte a caldo e anche le regole indesiderate possono essere rimosse dalle pipeline del processo.
Problema : presto il numero di file di progetto diventa così grande che la gestione dei file system dei progetti diventa un rompicapo. Che cosa succede se per un breve periodo di tempo il team di business ha bisogno di una personalizzazione speciale che dura solo per due mesi, e quindi dovrebbe essere rimosso dal sistema. Qualcosa come la registrazione prepagata per tracciare il comportamento degli utenti per prendere le decisioni reali. O una regola semplice come bandire i clienti con attività sospette che dovrebbero essere lanciati molto presto.

Sembra che il nostro team stia andando per il verso sbagliato. In che modo un team può gestire la creazione di software altamente complesso e altamente mutevole quando incontra i problemi specifici menzionati? Quali punti dovrebbe considerare quella squadra? Esistono architetture o progetti specifici che ci aiuteranno a creare questo software?

design architecture complexity business-logic changes

posta Saeed Neamati 27.11.2015 - 21:35

fonte

2 risposte

Leggi altre domande sui tag design architecture complexity business-logic changes

Buone pratiche per tenere le costanti nel proprio file? [duplicare] Come mantenere la documentazione aggiornata e accessibile [duplicato]

score 6 · Answer 1

Mi concentrerò sui due problemi principali descritti nella tua domanda:

Soon there are like hundreds of configurable options, and even naming them becomes a nightmare, let alone managing them, changing them, tracking them in code

Il problema di denominazione può essere risolto organizzandoli in gerarchie. Ad esempio, guarda le migliaia di opzioni che troverai nella pagina about: config del browser Firefox: sono ben strutturate e organizzate in gruppi di più livelli.

Il tracciamento nel codice dovrebbe seguire lo stesso principio: creare una gerarchia di oggetti o strutture di dati (in realtà, le gerarchie di denominazione e di codice dovrebbero corrispondere e una dovrebbe essere generata dall'altra). Naturalmente, questo da solo non è sufficiente, per centinaia di opzioni è necessario mantenere una documentazione formale in modo disciplinato (di nuovo, controllare come la comunità di Firefox risolve questo problema). Devi stabilire dei cancelli di qualità come le recensioni e dovresti pulire di tanto in tanto le cose. Alla fine, si tratta di un problema puramente organizzativo, ma in realtà non è affatto diverso dalla gestione di qualcosa come uno schema di database di grandi dimensioni.

Using small satellite project files as additives ... Soon the number of project files become so huge that the file-system management of the projects becomes a pain in the ass

In realtà non è diverso dal primo caso: gerarchie, documentazione formale, assicurazione della qualità e qualche disciplina ti aiuteranno anche qui. Inoltre, supponendo che gli additivi siano codice, non ci dovrebbe essere alcuna differenza reale per il codice che non sia "hot plug" - quest'ultimo fa solo una differenza per l'utente del sistema, ma non per la manutenzione da parte degli sviluppatori. Quindi devi preoccuparti delle stesse cose che hai sempre quando scrivi software più grande: dipendenze, architettura pulita, codice SOLID ecc.

Come hai detto "un business team": un'altra opzione per mantenere "additivi" più gestibili è fornire un meccanismo di estensione come un linguaggio di script o di query, in modo che il tuo team aziendale possa scrivere tali additivi per conto proprio. Ciò comporta l'onere di gestire le estensioni dal team di sviluppo agli utenti del sistema sul "lato business". Anche se sembra proprio come cambiare il problema, può davvero aiutarti, perché crei un confine stretto tra il tuo sistema principale e quelle estensioni, con in totale più persone coinvolte per le attività di gestione che ti danno mal di testa.

E forse le persone che "inventano" tutti questi nuovi requisiti penseranno due volte a quello che fanno, se devono scrivere questi script da soli.

Un'ultima cosa da aggiungere: raccomando vivamente di mantenere le nuove opzioni "ortogonali il più possibile". In altre parole: ogni nuova opzione dovrebbe avere il minor numero possibile di dipendenze rispetto ad altre opzioni esistenti, idealmente nessuna. Ciò significa in genere dividere i nuovi requisiti per "una sola opzione" in diverse opzioni più piccole, ma posso dire dall'esperienza che veramente un fattore chiave per mantenere gestibile un tale sistema.

score 1 · Answer 2

Le persone che lavorano nelle linee di prodotti software spesso si confrontano con gli stessi problemi: come scrivere software che può variare a seconda dell'ambiente di distribuzione. Esistono diversi metodi che sono stati identificati per gestire la variabilità: configurazione del build-time, modelli di architettura plug-in, configurazione di proprietà di run-time, file di configurazione, estensione o modifica del codice sorgente per ciascuna variante. Tuttavia, come hai trovato, non esiste una soluzione perfetta. Ci sono solo compromessi tra le opzioni.

Per rispondere alla tua domanda - sì, ci sono processi e metodi, strumenti, architetture e sistemi software costruiti che raggiungono quello che stai cercando di ottenere. Tuttavia, senza una comprensione più approfondita del tuo sistema software e della tua organizzazione, non è possibile fornire indicazioni su cosa, esattamente da fare.

Il campo delle linee di prodotti software è molto grande. Si va dallo sviluppo dei requisiti alla manutenzione del software e comprende la struttura organizzativa, la gestione di progetti e programmi e altro ancora. I libri Linee di prodotti software: pratiche e modelli e Linee di prodotti software in azione: la migliore pratica industriale nell'ingegneria della linea di prodotti può darti una buona introduzione all'ingegneria della linea di prodotti, che affronta la variabilità e il riutilizzo. Più incentrato sul riutilizzo del software è Riutilizzo del software: architettura, processo e organizzazione per il successo aziendale .