Il "punto di eccessiva complessità" è riferito in inglese come:
OH MIO DIO CHE COSA È QUESTO CORAGGIO.
Il problema è che questo può essere applicato a qualcosa che in realtà è semplice, ma è implementato in modo così orribile da avere la stessa reazione.
Quindi distinguere qualcosa di molto complesso da qualcosa di molto orribile può essere difficile.
TUTTAVIA: ciò che in realtà tende a succedere a tutto il software è un processo simile a questo:
Passaggio 1: avere una buona spec, fare un bel design, implementare cose carine. Tutti felici.
Alla fine del passaggio 1: gli sviluppatori si congratulano con loro per la meravigliosa eleganza del loro design, e vanno via pensando felice "Ho una meravigliosa eredità qui per gli altri per aggiungere cose in futuro, sarà meraviglioso e il mondo sarà un posto migliore. "
Passaggio 2: alcune modifiche vengono apportate, le cose vengono aggiunte, nuove funzioni sono incluse. L'architettura e la struttura del passaggio 1 hanno reso questo processo abbastanza indolore. [Ma oops, il "fattore cruft" è appena aumentato un po '.]
Alla fine del passaggio 2: gli sviluppatori si congratulano con loro per la meravigliosa eleganza del loro design, e se ne vanno via pensando felice "Accidenti, sono così intelligente da aver fatto tutti questi assegni nel passaggio 1. È andata così bene. un meraviglioso lascito per gli altri in futuro, sarà meraviglioso e il mondo sarà un posto migliore. "
Passaggio 3: più modifiche vengono apportate, più cose vengono aggiunte, più nuove funzioni, un sacco di cose vengono cambiate, il feedback degli utenti viene effettivamente ascoltato.
Alla fine del passaggio 3: gli sviluppatori si congratulano con loro per la meravigliosa eleganza del loro design, e vanno via pensando abbastanza felice "Accidenti, questa architettura è abbastanza buona da permettere a tanti cambiamenti di inserirsi facilmente. un po 'scontento di X e Y e Z. Potrebbero essere ripuliti un po' ora, ma !!! Ahhh !!! Sono così intelligente da aver fatto tutti questi assegni nel passaggio 1. È andata così bene. legacy qui per gli altri per aggiungere cose in futuro, sarà meraviglioso e il mondo sarà un posto migliore. "
Passaggio 4: proprio come il passaggio 3. Tranne:
Alla fine del passaggio 4: gli sviluppatori pensano: "Questa roba che era così buona è stata mantenuta da UGLY. Ha davvero bisogno di alcuni cambiamenti seri, non mi piace lavorare su questo, ha bisogno di refactoring. quello che dirà il capo quando gli dirò che ha bisogno di 6 settimane e non ci sarà nulla per gli utenti da vedere alla fine di questo ... ma avrò altri 5 anni di buonissimo scopo di modifica futuro facendo questo .... hmmm ... tempo di andare al pub per un po 'di birra. "
Passaggio 5: è necessario apportare alcune modifiche.
E DURANTE il passaggio 5 gli sviluppatori si dicono l'un l'altro: "Questo codice fa schifo." Chi ha scritto questo? Dovrebbero essere fucilati. È orribile. Dobbiamo riscriverlo. "
Il passaggio 5 è fatale. Questo è il punto in cui il fattore cruft è diventato così grave che il codice non può avere solo qualche cambiamento in più, ma deve avere alcune modifiche GRANDI.
Il problema al punto 5 è il desiderio di buttarlo via e ricominciare. Il motivo per cui questo è fatale è "The Netscape Factor". Vai su google. Le aziende muoiono a questo punto, perché ricominciare significa iniziare con circa il 50% di ipotesi anziché fatti, il 150% di entusiasmo invece di conoscenza, il 200% di arroganza invece di umiltà ("Quei ragazzi erano così stupidi!"). E tu introduci un sacco di nuovi bug.
La cosa migliore da fare è refactoring. Cambia un po 'alla volta. Se l'architettura è un po 'stanca, risolvila. Aggiungi, estendi, migliora. Gradualmente. Ad ogni passo lungo il percorso, prova, prova e prova ancora. Cambiamenti incrementali come questo significano che 10 anni dopo il codice attuale e quello originale sono come l'ascia dei nonni ("aveva 10 nuove teste e 3 nuove maniglie ma è ancora ascia nonno"). In altre parole, non è rimasto molto in comune. Ma sei passato dal vecchio al nuovo gradualmente e attentamente. Ciò riduce il rischio e, per i clienti, riduce il rischio di incazzare.