Ho incontrato il criterio del buon sistema di design in quanto la sua stabilità rispetto ai requisiti cambia.
Piccolo req. le modifiche dovrebbero sollevare piccole modifiche nel design.
Tuttavia, ho la sensazione che quasi per qualsiasi sistema software un po 'complesso è possibile indicare l'insieme di piccoli cambiamenti nei requisiti che causano quantità inaccettabili di cambiamenti nel software.
Questo sentimento si basa sull'esperienza personale anche se non eccezionale e sul fatto che i programmi sono spesso infranti.
La community può contestare questa affermazione in caso di strong disaccordo.
Ma la domanda ha un significato solo se sei d'accordo.
Il principio YAGNI funziona bene contro la sovrintendenza e la metodologia Agile la porta all'intero processo di sviluppo del software: il sistema si evolve in modo incrementale e questo si adatta perfettamente al concetto di stabilità da cui ho iniziato questo post.
Ma ... Se tuttavia concordiamo sul fatto che ci sono alcuni punti di instabilità, non dovremmo localizzare questi casi per capire le implicazioni fin dall'inizio? E come è possibile se progettiamo il sistema in modo agile e incestuoso?!
P.S. Parte interessante del dialogo con il mio collega:
- Non c'è niente di sbagliato nello sviluppo incrementale del software.
- Ti immagini i costi di modifica dell'architettura del firmware di Curiosity dopo che è atterrato su Marte?
- Ehi, ma è possibile e ha cambiato il firmware!
- Sì, ma prima, avevano progettato attentamente questa funzione. E se no ... quello sarebbe il punto di non ritorno.