Come dovresti gestire la situazione?
Hai identificato il potenziale di miglioramento. Ma i pattern sono solo mezzi per progettare il software in modo migliore e più veloce. Quindi, quando il software è già stato progettato e implementato, non vi è alcun obbligo di adottare i modelli più recenti.
Se il tuo sistema ha un design modulare e consente di sviluppare nuovi componenti senza una dipendenza significativa dai costrutti esistenti, fai come il tuo capo ha detto: -)
Come pensa il tuo capo?
Argomenti tecnici:
- "Non cambiare mai un sistema in esecuzione": la modifica dei modelli richiederebbe una riprogettazione estesa, che potrebbe propagarsi rapidamente attraverso le dipendenze e l'end-up in una revisione completa del sistema
- Se è richiesto tale cambiamento, come gestire il rischio di instabilità durante la reimplementazione?
- Come può essere testata la nuova versione? Se è stato utilizzato TDD, è sufficiente riutilizzare tutti i casi di test e il rischio è gestito. Ma se no, sono tutte le prove che dimostrano che l'affidabilità è ancora nota?
Argomenti commerciali:
- Quali benefici apporterebbe al cliente il cambiamento dei modelli?
- Qual è il costo del reimplementing e quali benefici economici (riduzione dei costi, entrate) potrebbero portare? E come si confronta questa immagine con il costo sostenuto mantenendo gli schemi esistenti?
- Qualcuno è pronto a pagare per la modifica?
Come pensa l'utente?
Pensano:
- Ho molto lavoro da fare e il sistema dovrebbe aiutarmi
- È stata intrapresa una riprogettazione importante, ma nulla cambia per il mio lavoro quotidiano, tranne che potrebbero esserci molti nuovi bug da gestire.
- Non ho tempo per investire in un enorme test di accettazione, solo per oscure questioni tecniche.
Conclusione
Non ho le risposte a tutte queste domande. Il tuo capo ha sicuramente fatto questo tipo di analisi. Questo è ciò che i capi sono pagati per fare. Quindi lavora come ti ha detto :-) ...
... a meno che tu non pensi che i vecchi schemi abbiano importanti svantaggi che non sono completamente compresi dal tuo capo. Ad esempio, se i vecchi schemi rendono il sistema difficile da gestire e mantenere ("debito tecnico"). In questo caso dovresti tornare dal tuo capo e assicurarti di comprendere i costi nascosti dell'eredità nella sua analisi costi / benefici.