Lo Spaghetti Code è una definizione piuttosto conosciuta tra gli sviluppatori ed è altamente probabile trovarlo nei software scritti qualche anno fa, soprattutto quando si usavano librerie che non facilitavano la programmazione object oriented (vedi MFC ad esempio). Per fortuna con il .NET Framework le cose sono migliorate notevolmente.
Uno degli effetti più comuni dello Spaghetti Code è che, dalla seconda release in avanti, ogni richiesta di modifica del cliente viene vista malamente, in quanto gli effetti sul codice già scritto non sono facilmente prevedibili.
Oggi si può assistere al problema opposto; vedere un progetto con migliaia di piccole classi con uno o due metodi al massimo, cioè il software passa da una struttura monolitica a una struttura polverizzata. Ebbene a questo eccesso è stato dato un nome, sempre nell'ambito culinario, Ravioli Code.
L'effetto del Ravioli Code è di guardare un progetto e non avere la più pallida idea di cosa facciano queste migliaia di micro classi.
Una buona Rule Of Thumb viene data qui dove una classe dovrebbe avere mediamente 7 metodi +/- 2.
Uno dei rischi del TDD, se applicato in maniera errata, è quella di scrivere appunto del Ravioli Code, esistono tuttavia alcune tecniche di refactoring che permettono di ovviare al problema:
- Inline class: Spostare tutte le funzionalità in un altra classe e cancellare la classe di origine.
- Replace Subclass with Fields: Le sottoclassi variano solo in metodi che ritornano un valore costante.
- Collapse Hierarchy: La sottoclasse è molto simile alla classe base, si possono unire in un unica classe.
Può darsi che abbia dimenticato qualche refactoring, se è così scrivetemeli nei commenti che modificherò il post.