Mi sono reso conto di essere proprio un estremista del codice "corretto".
Non voglio scendere nel dettaglio di cosa intendo personalmente per codice "corretto", ma facendo passare una descrizione imprecisa ed un po' improvvisata potrei dire che workaround, convenzioni implicite (i classici "facciamo che lì... tanto non succederà mai che...") ed, in un certo senso, anche gli idiomi stessi (solo in un certo senso...) proprio non mi piacciono!
E' chiaro: di sicuro ogni giorno commetterò decine di errori, ma quantomeno posso affermare di farlo inconsapevolmente. Non mi piace "chiudere un occhio", mi sentirei un po' "losco" e soprattutto saprei che, prima o poi, la mia omertà molto probabilmente mi si ritorcerebbe contro in futuro, proprio impazzendo sulle eventuali modifiche relative a quel codice.
Ma allora come si può fare a portare a casa la pagnotta?? Scrivere codice "come si deve" richiede tempo (tradotto: rende meno competitivi economicamente) e come ben si sa non sempre il cliente è disposto a sostenere un costo che "appare" come più elevato, oppure banalmente non ne ha in buona fede la possibilità!
Beh, IMVHO, l'unica strada percorribile è... abbassare ancora il costo di produzione, ottimizzando il processo di creazione del software.
L'OOD (mi perdonino i grandi dell'object oriented per quanto scrivo) a mio avviso è un OTTIMO strumento di ottimizzazione. Stabilisce limiti, contratti, competenze; incapsula, snellisce e rende assolutamente più leggibile il codice (se scritto in modo decente, ovviamente!) . Ok, ok, lo so... sfondo una porta aperta: come scrivere oggi che Vale è un campione! 
L'altro "strumento" che sto iniziando ad apprezzare sempre di più sono i CodeSnippets di Visual Studio 2005. Mi sono reso conto di recente che alcuni forse non conoscono ancora questa funzionalità e parlando di CodeSnippet giustamente pensano che mi riferisca a semplici "stralci di codice".
I CodeSnippet di Visual Studio 2005 sono invece dei file in formato XML che vengono elaborati da VS, su richiesta dell'utente, e permettono al tool di scrivere per noi parti di codice che ci interessa permettendo di personalizzarlo in pochi istanti, con estrema facilità ed in ogni dettaglio sulla base delle nostre necessità.
Già qualche settimana fa ho elogiato questo strumento (a proposito, per quanto riguarda la possibilità citata di creare uno "store" di snippets se ne parlerà prossimamente sul forum) ma oggi mi sonoimbattuto in un esempio ancor più esplicito di quanto possa essere fondamentale l'utilizzo di code snippets proprio nel contesto di ottimizzazione della scrittura di "buon codice".
In breve: immaginate un contesto in cui ci si stia basando sul polimorfismo per una scelta di design.
Premetto che per me (IMVVVVVHO) i contratti "sono" le interfacce e non le classi astratte.
Supponiamo che il 30% del codice di quella particolare soluzione sia comune a tutte le implementazioni concrete, dovrei crearmi una classe astratta, con metodi astratti e virtuali e basarmi su questi per far "girare il tutto".
Facendo questa scelta 1) mi gioco a priori l'ereditarietà 2) rischio di far arrabbiare chi ha scritto la famosa "Favour object composition over inheritance" 3) se un domani arrivano gli alieni (e a volte nell'informatica succede...) ed una parte di quel 30% di codice non va più bene per nuove parti prendo una mazza da venti chili e imito Giacomo tirandomela...
D'altro canto non ha forse neanche senso basarsi totalmente sul refactoring (che, come dice il nome, non è propriamente una scelta di design) ed estrapolare in una classe "condivisa" quel codice...
E allora (come probabilmente molti faranno già da anni!!) baso il contratto su un interfaccia e creo una classe astratta che implementa quell'interfaccia. In questo modo posso (non "devo") derivare le classi concrete da quella astratta.
Ok, ma il restante 70% del codice? Qui entrano in scena i Code Snippets!
Supponete che il restante 70% debba essere per forza diverso ma magari in realtà sia estremamente "simile": penso ad esempio al riempimento di una ListView che non può essere "genericizzato" (basta considerare che le colonne sono sempre differenti in numero e caratteristiche) ma in realtà è molto simile nella sequenza.
Ogni volta la "tiritera" è quella: svuoto la ListView, recupero i dati dal layer sottostante gestendo eventuali eccezioni, itero gli oggetti della collection tipizzata per creare nuovi ListViewItem e relativi SubItems, bla, bla, bla...
Solitamente io sono capace proprio in quei loop di noia di cacciar dentro qualche bella boiata!!! 
Soluzione alternativa? Richiamo da Visual Studio (tasto destro sul Text Editor o, non in VB, "codice shortcut" come ad esempio mbox) uno snippet che popola i ListView "come voglio io" (d'altronde...oh: l'ho scritto io!), scrivo una volta il nome del tipo di entità che sto elencando, scrivo una volta il nome del controllo ed ho finito!
Moltiplicate questa situazione per l'implementazione di tuti i metodi e le proprietà astratte (magari unendo tutto in un unico snippet implementativo per quella classe astratta) e vi ritrovate ad aver investito mezz'oretta per poi risparmiare un botto di tempo, rendendo le varie implementazioni, per di più, molto più simili tra di loro (quindi leggibili e mantenibili)!
E tutto questo, IMHOBMT (in my humble opinion but mia trop ), è uno dei modi per ottimizzare il processo di creazione del software.
Oops... voleva essere un post "al volo" e ne è venuto fuori un romanzo... chiedo scusa, dev'essere l'acqua e menta che è stata "alterata" da qualche agente esterno!!
