Strutture di database modulari

1

Ho esaminato il codice base che utilizziamo nel lavoro e sono preoccupato per le dimensioni del i pacchetti sono cresciuti. Il codice attuale è modulare, le procedure sono state suddivise in piccole parti funzionali (e verificabili). Il problema che vedo è che abbiamo 100 procedure in un unico pacchetto - quasi un intero modello di dominio.

Avevo pensato di rompere questi pacchetti giù - per creare sottodomini che sono centrati attorno alle relazioni della procedura con altri oggetti. Raggruppa un gruppo di procedure che hanno l'80% delle loro relazioni in tre tabelle, ecc. Il risultato finale sarebbe molti più pacchetti, ma i pacchetti sarebbero più piccoli e ritengo che l'intera base di codice sarebbe più leggibile - quando le procedure si incrociano tra due modelli di dominio è meno difficile stabilire quale pacchetto appartenga.

Il problema che ora ho è quello che sarebbe davvero il vero vantaggio di tutto ciò. Ho esaminato i vantaggi generali della modularità:

1. Re-usability
2. Asynchronous Development 
3. Maintainability

Tuttavia, quando considero il nostro ultimo sviluppo, le procedure all'interno dei pacchetti sono già riutilizzabili. In questa fase avanzata raramente abbiamo bisogno di uno sviluppo asincrono e, quando è necessario, semplicemente scaliamo le storie attraverso iterazioni.

Quindi immagino che la mia domanda sia se le persone conoscono i motivi per cui abbatterebbero le classi piuttosto che i metodi all'interno delle classi? In questo momento credo che ci sia un problema con questi mega pacchetti che si stanno formando, ma l'unico vantaggio che posso veramente definire per abbatterli è la leggibilità - qualcosa che l'esperienza acquisita lavorando con loro risolverebbe.

    
posta John D 01.07.2012 - 18:38
fonte

1 risposta

1

Right now I do believe there is an issue with these mega packages forming but the only benefit I can really pin down to break them down is readability

Bene, IMHO il punto che ti manca qui è l'incapsulamento migliore. Se si aggiunge una nuova funzionalità a un mega pacchetto con 100 funzioni, potrebbe essere necessario verificare gli effetti collaterali o cose simili in tutte queste 100 funzioni (YMMV a seconda del problema effettivo). Se dividi il pacchetto in 5 pacchetti più piccoli, puoi probabilmente gestire tale modifica più facilmente, poiché potrebbe avere un impatto su un'area più piccola del tuo codice.

Tuttavia, quando si cambiano raramente i pacchetti e le funzioni, è necessario considerare se un refactoring di questo tipo vale la pena - un grande refactoring non dovrebbe mai essere applicato solo per il gusto di se stesso. E suppongo che tu non abbia alcun browser di refactoring per PL / SQL che potrebbe aiutarti (esiste una cosa del genere?), Quindi una tale ristrutturazione potrebbe significare molto lavoro.

    
risposta data 01.07.2012 - 21:54
fonte