Regole aziendali di versioning

3

TL; DR

Memorizzazione di regole aziendali in continua evoluzione in modo che un'app possa comportarsi come nel momento X in passato. Può essere fatto? Se sì, come?

Versione lunga

In questo momento, questo è più un esercizio di pensiero che un bisogno reale, anche se le cose potrebbero cambiare in un futuro non troppo lontano.

La società per cui lavoro è nel settore delle buste paga. Abbiamo un'applicazione desktop il cui compito è principalmente quello di calcolare l'ammontare dello stipendio che un dipendente riceverà. In Italia questo è un lavoro in sé e per sé, perché le cose cambiano letteralmente ogni mese, con nuove tasse, fusioni di vecchie, diversi calcoli che devono essere fatti. In breve, è un pasticcio terribile e terribile.

Non fa alcuna differenza, ma questa è un'app COBOL (non chiedere) ed è abbastanza grande, con un clock stimato di 5M LOC. Inoltre, affermando che invece di essere progettato male non ha alcun disegno di base, sarebbe un modo delicato.

Per chissà quale motivo, i clienti devono essere in grado di ricalcolare i libri paga passati. Certo, hanno bisogno che il programma si comporti come ha fatto in quel preciso mese.

Un po 'da parte: personalmente, questo non ha senso per me, perché una volta pagato il ragazzo, l'unica cosa che potresti essere in grado di fare è aggiustare le cose il prossimo mese, e mantenere i dati risultanti (che non è solo il salario, ma migliaia di altre informazioni) in un archivio per le domande successive sarebbe il più banale degli esercizi. Quindi, ancora una volta, non ho nulla a che fare con la manutenzione quotidiana di questa app, quindi le precise ragioni dietro questi requisiti potrebbero semplicemente sfuggirmi a causa di ciò. Potrei essere coinvolto, almeno in parte, nella progettazione di una profonda revisione dell'intera faccenda, però, ed è per questo che sto scrivendo questa domanda. Quindi, supponiamo che questo sia un requisito reale.

Quindi, ciò che questa app fa ogni mese è che copia tutte le sotto-app di cui è composto in una nuova cartella, insieme a una copia completa dei suoi dati. Una copia di quasi tutto, che finisce per mangiare un'enorme quantità di spazio sulle macchine dei clienti.

Non usa un database, è ancora bloccato con i file indicizzati (di nuovo, non chiedere).

Ora la domanda: come progetteresti se potessi ricominciare da capo? Sia che si trasformi in un'applicazione web o che si crei un'altra app per desktop, sono più interessato al lato concettuale .

Come progettereste un'app che deve mantenere aggiornate le regole di business e e riapplicare quelle vecchie su richiesta?

Ora può essere fatto facilmente perché in realtà copiano l'intera shebang una volta al mese e ogni pezzo di dati viene memorizzato in file indicizzati.

Con un'app progettata correttamente, però, non saprei come affrontarla in modo elegante: gli schemi di database tendono a cambiare, ad esempio, e fare una copia dell'intera cosa ogni mese sarebbe solo un incubo.

Ma il nocciolo della questione è la versione delle regole aziendali: può anche essere fatto? Una cosa che farei sicuramente sarebbe naturalmente tirarli fuori dal codice reale e in una serie di script, perché ora, come nella migliore tradizione COBOL, tutto è cablato nel codice, quindi ricompilano e spediscono anche se è stato modificato un semplice calcolo.

Dove andare da lì, però, è un po 'un mistero.

    
posta s.m 13.11.2014 - 23:13
fonte

1 risposta

2

La difficoltà è che devi affrontare regole già complesse che cambiano ogni mese. Vorrei pensare a due tecniche che possono essere utilizzate per attenuare una certa complessità:

  1. Non memorizzare regole storiche nel codice . A meno che non ci siano molti errori contabili e la tua azienda ha bisogno di ricalcolare spesso la busta paga, non è necessario mantenere tutta questa complessità.

    Allo stesso tempo, per la verifica, è possibile creare un motore che costruisca un report delle regole attuali per un dipendente specifico, ovvero una parte di dati più o meno programmatica, più o meno umanamente leggibile che mostri come è stato determinato lo stipendio specifico.

    La memorizzazione di tali rapporti finali non sprecherebbe molto spazio e fornirebbe informazioni sufficienti in un caso in cui un dipendente ritiene di essere sottopagato.

  2. Non gestire ogni caso possibile. Potrebbe essere troppo costoso mantenere il codice, molto più costoso che pagare un contabile che farà a mano lo stesso lavoro del software.

    Se:

    • Ci vogliono 30 minuti per un contabile per calcolare a mano il salario di un dipendente,

    • La tua azienda ha 600 dipendenti, 10 con uno stato specifico che richiede l'applicazione di alcune complicate logiche di business,

    • Ci vogliono due giorni per implementare quelle complicate regole aziendali,

    quindi è meglio tenerli fuori dal codice e concentrarsi su situazioni semplici. Se trascorri più tempo nello sviluppo di una funzione rispetto a quella che salva nei tuoi clienti, non svilupparla.

Se hai davvero bisogno di mantenere tutte le regole aziendali per ogni mese passato, potresti essere interessato dall'architettura dei plugin, con i plugin caricati su richiesta dall'applicazione (ad esempio il plug-in September2014 caricato quando è necessario creare il libro paga per Settembre 2014). Ciò ti garantirà di mantenere l'applicazione pulita e di mantenere le regole per un mese specifico il più semplice possibile. Lo svantaggio è che potresti avere molta duplicazione del codice.

Si noti che in questo caso può essere utile l'utilizzo di NoSQL basato su documenti anziché di sistemi SQL ordinari con uno schema rigoroso. Con SQL ordinario, una volta modificato lo schema, i vecchi plugin potrebbero smettere di funzionare. Con NoSQL, sei libero di memorizzare ciò che vuoi in diversi documenti corrispondenti a diversi mesi; puoi ancora utilizzare i plug-in precedenti, con l'unica limitazione di non poter caricare con i vecchi plugin documenti archiviati con nuovi plugin (ma perché lo faresti?)

    
risposta data 13.11.2014 - 23:40
fonte

Leggi altre domande sui tag