(luKa)

1. Facilità di trovare dove fare la modifica
   
   Dipende in gran parte dalla attenzione con cui si sono scelti i nomi per i parametri,  metodi, le classi, i namespace e gli assembly e il modo in cui le classi sono raggruppate in namespace e i namespace raggruppati in assembly.
   
   Questo è descritto anche da un attributo di qualità standard detto 'Analizzabilità'
   E' la prima caratteristica del codice che avverto quando inizio a lavorarci.
   
   
   
   
   
2. Facilità di capire come fare la modifica
   
   Dipende in gran parte da quanto lunghe sono le classi (se hanno 5-10 metodi invece che 20-60 e 2-4 field invece che 20-50) , da quanto solo lunghi i metodi (se sono di 5-20 righe invece che 100-1000 righe) e da quanto è complesso il codice nei metodi (se ha 1-4 if e for non nidificati invece che 10-30 nidificati 2 e più volte).
   
   E dipende da quanto ogni responsabilità è assegnata/implementata in una singola classe o poche classi correlate (dello stesso namespace) invece che essere sparsa in molte classi diverse e scorrelate; e da quanto l'implementazione è in un unico punto invece che essere duplicata in diverse parti.
   
   Nella terminologia del buon disegno OO questo si indica come disegno flessibile.
   Questo è descritto anche da un attributo di qualità standard detto 'Modificabilità'
   
   E' la seconda caratteristica del codice che avverto quando inizio ad abozzare e stimare l'implementazione.
   
   
   
   
   
3. Velocità nel verificare l'impatto della modifica sulle altre funzionalità
   
   Dipende in gran parte da quanto ogni metodo fa una cosa sola (esegue una sola operazione invece di svolgere più compiti diversi legati dal solo fatto di dover essere eseguiti nello stesso momento, vedi Cohesion), da quanto ogni classe assolve a una singola responsabilità (vedi il Single Responsibility Principle) e da quante dipendenze ha il metodo e la classe (se dipende da 1-4 altri tipi astratti invece che 10-20 altri tipi in gran parte classi concrete).
   
   E dipende da quanto la visibilità usata per i metodi è la minima necessaria (private o internal invece che public), da quanto le variabili sono dichiarate nello scope più ridotto possibile (dentro un blocco di codice o a livello di metodo invece che a livello di classe) e di quanto le variabili statiche e globali sono state evitate.
   
   Nella terminologia del buon disegno OO questo si indica come disegno robusto oppure come basso accoppiamento.
   Questo è descritto anche da 2 attributi di qualità standard detti 'Stabilità' e 'Provabilità'
   
   E' la terza caratteristica del codice che avverto quando inizio a scrivere i test e a scrivere l'implementazione.
   
   
   
   
   
4. Il codice esistente si evolve estendendolo invece che modificandolo
   
   Dipende in gran parte da quanto i concetti del dominio applicativo e del livello di implementazione sono rappresentati nelle classi del sistema (se concetti distinti sono rappresentati da classi distinte invece che essere implementati da una stessa classe) e da quanto i concetti più stabili sono stati rappresentati con tipi astratti (interfacce che permettono diverse implementazioni concrete) mentre quelli più passibili di cambiamento con tipi concreti (da cui devono dipendere poche classi).
   
   Nella terminologia del buon disegno OO questo si indica come disegno riusabile e alta coesione.
   Anche questo è descritto con l'attributo di qualità standard 'Modificabilità'.
   
   E' la quarta caratteristica del codice che avverto quando inizio a scrivere i test e a scrivere l'implementazione.
   
   
   

Un codice che ha le caratteristiche 1 e 2 e in parte la 3 lo considero buono e mi permette di fare un buon lavoro in poco tempo.

Un codice che ha completamente anche la caratteristica 3 lo considero ottimo.

Uno che ha anche la 4 lo considero straordinario!!!

  Tags :  Team Work | Agile | Pratiche | Progettazione Software |