Iniziamo con una semplice, ma molto importante constatazione: è nell'interesse del cliente mantenere meno codice possibile.
Dato un qualsiasi problema, è da considerare la soluzione migliore e più elegante quella che lo risolve con la complessità minore
.
In altre parole disporre di un sitema che svolge efficacemente un compito è un Asset, ma nel momento in cui è mal costruito e costa più dello stretto necessario per essere mantenuto diventa una Liability.
Non c'è accordo su come misurare la complessità di un programma, tuttavia due metodi sono comunemente impiegati:
Saltiamo la descrizione della complessità ciclomatica
perché poco utile in questa sede ed utiliziamo il più semplice KLoC, nota che non ha senso paragonare KLoC di programmi diversi,
men che meno se epressi in linguaggi diversi,
ma ritengo utile paragonare questa grandezza sullo stesso programma, in altri termini, a parità di problema e correttezza della soluzione,
è sempre preferibile la soluzione realizzata con meno quantità di istruzioni.
Mantenere un programma più complesso costa di più perché un programma è come una qualsiasi macchina, va mantenuta efficiente nel corso della propia vita produttiva, maggiore è la sua dimensione e complessità in termini di numero di singole parti in movimento e maggiore sarà il costo della manutenzione e la possibilità che qualcosa si "usuri".
Maggiore la quantità di parti che compongono la macchina e maggiore sarà il tempo necessario ad un tecnico per impararne il funzionamento e riparare parti fisicamente "nascoste" o "inaccessibili".
Le attività necessarie alla manutenzione di un programma sono:
Tutte queste attività hanno un costo in termini di tempo che aumenta all'aumentare della grandezza del programma.
Supponiamo che i programmi A e B trattino la business logic della stessa complessità,
il programma A sia costruito in 1000 linee di codice, modificarlo per aggiungere una funzione costa 1 ora.
Il programma B di 10000 linee di codice, richiede molto più di 10 ore di tempo per essere capito e testato completamente,
un intervento errato può dare ripercussioni in parti inattese del programma, per cui una modifica simile
a quella del primo programma finirà per impegnare molto più tempo
(vedi Steve McConnell's Code Complete 2
).
è invece cattiva paritica riutilizzare intere procedure perché una procedura concepita per risolvere un problema diverso porterà con sè elementi non utilizzabili e questi diventano un peso, uno spreco, non un asset.
Per mantenere in modo efficiente ed economico gli assets software, assicurati di concordare con il tuo team di sviluppo soluzioni dalla complessità più bassa possibile e monitora la quantità di codice che viene prodotto.
Average programmers solve simple problems with complex solutions. Good programmers solve complex problems with complex solutions. Great programmers solve complex problems with simple solutions.
Le opinioni espresse nel mio blog sono solo questo: mie opinioni.
In nessun modo rappresento le opinioni dei miei clienti in questa sede.
Partita Iva: 02360450205
Content of this site is licensed under Creative Commons Attribution-Share Alike License.
