Originariamente inviato da longilineo
Non sono d'accordo l'impegno nello scrivere buon codice flessibile e facilmente espandibile è conseguenza di buona remunerazione occorre giudizio e sapere quando è meglio farsi poche pippe mentali e limitarsi a fare il giusto.

L'altro giorno un amico che sviluppa da tanti anni per un progetto più grosso del solito ha deciso di implementare Repository. A una settimana da quando aveva scritto il codice aveva problemi a ricordare come aveva strutturato il codice e a dirla tutta il lavoro non è che fosse poi così grande o contenesse una mole di dati tale da richiedere chissà quale scalabilità.
Questo è un esempio di come sia meglio a volte farsi poche pippe mentali e non strafare.
I design pattern sono strumenti potenti quando servono e quando uno sviluppatore li ha fatti propri e non è una cosa tanto semplice o che si acquisisce dall'oggi al domani.
A contrario di quanto si possa pensare usare i design pattern non consente di scrivere codice più semplice o più breve.

Ciò non toglie che alcune pratiche siano da evitare come la peste, ma per questo il più delle volte basta il buon senso.
ahahahahah bello sto discorso! Cioè tu mi porti d'esempio uno che "sviluppa da tanti anni" e che invece di usare un framework già pronto per la persistenza se lo implementa a mano? E cmq, prima di applicare un pattern o un altro uno dovrebbe farsi un pò di conti e vedere i pro e contro di ogni decisione.

I design patterns non servono per scrivere codice più semplice o breve, anzi in genere nel 99% dei casi è più "complesso" e lungo, ma servono semplicemente a risolvere i problemi per cui sono pensati e a non dover reinventare la ruota ad ogni nuovo progetto.

Su una cosa ti dò ragione: programmare nn vuol dire applicare a mani basse design patterns, anzi l'idea che ci sia un design pattern per ogni problema è sbagliata, quindi vada per il "buon senso" (chiamiamolo "buona programmazione" non credi?) e un programma scritto al 50% da patterns e al 50% da una buona progettazione