Le malattie professionali del programmatore :: 02 La Sindrome di Setter

Continuiamo la serie di post sulle malattie professionali del programmatore.
Parliamo della Sindrome di Setter.

Un po' di storia

Casi di questa sindrome sono segnalati fin da tempi remoti.

Sintomi

La Sindrome di Setter è come un "raffreddore". Ogni tanto lo prendi.
E' facile: hai un database, 4-5 tabelle, inciampi su una business logic semplice (oggi) o "fatta semplice" e...

PRESAAAAAAA!!!

Gli oggetti diventano la traduzione 1-1 dei record di una tabella. Puoi cambiare ogni campo come vuoi. Si accompagna di solito con la Managerite, perchè appena la business logic si complica, quell'oggetto (ma perchè non chiamarlo RECORD?) non vorrai mica che "contenga della business logic"... EH NO! Allora nascono gli oggetti con nome <oggetto>Manager (ah e ovviamente stateless mi raccomando eh!).
Da questo momento in poi: degrado esponenziale del dominio e diminuzione drastica della possibilità di comprendere in futuro:
    "perchè cappero avevamo fatto questa applicazione?!?"
    "BOH!"
    "meglio rifarla da capo..."
    "EH?!?"
Scusate, ma se non si è riusciti a scrivere un'applicazione leggibile, come si puo' pensare che la cosa non si ripeterà in futuro?

Cure

La cura si chiama refactoring, ma è un'arte che non si puo' spiegare in un post.
Sono invece interessanti le manovre preventive che non coinvolgono solo noi programmatori, ma anche altri soggetti coinvolti nei progetti.
Ne suggeriamo alcune:

• alle parole: "guarda è una cavolata... abbiamo già anche il data model" è richiesto alcoltellamento dell'individuo
• se alla domanda: "ma cosa deve fare questa applicazione?", la risposta che vi vien data è "mah... c'è un DB, 4 oggettini, un frontend... dici di usare Hibernate o JDBC?" è necessario tapparsi le orecchie e urlare a squarciagola BLAH BLAH BLAH (come nella foto, ma mi raccomando... la lingua di fuori!)
• se è farina del vostro sacco dipende dalla vostra preparazione:
• se siete Juñor: non preoccupatevi... altamente suggerita la lettura del libro Domain-Driven Design: Tackling Complexity in the Heart of Software, perchè con i suoi ubiquitous language e building blocks si riesce a non cadere in questa trappola. Fatevi aiutare a sistemare la situazione da qualcuno con un po' più di esperienza... ma non nel (suo) periodo influenzale
• se siete Señor: refactoring immediato ora e subito. Non c'è tempo da perdere. La frittata è stata fatta... ok, capita, ma è il momento di risolverla e devi farlo tu anche a costo di far straordinari!

Ora scusatemi, ma... ehm... ho del lavoro arretrato e devo fare gli straordinari;)