Sei riuscito a implementare schemi di progettazione in tempi stretti?

It is a lot more work and programming overhead to get it right the first time and within time frame.

Questo è falso.

Senza il beneficio di qualcuno che ha già pensato al modello di progettazione, spiegandolo e documentandolo, sarebbe due volte più difficile.

Un modello di design semplifica tutto il pensiero e la meraviglia e la decisione.

Non devi inventare qualcosa di nuovo. Puoi usare qualcosa che è già ben compreso da te stesso e dagli altri.

I modelli di progettazione ti consentono di pensare meno. Questo è davvero l'intero punto. C'è un po 'di falsa dicotemia implicita nella domanda. Suggerisce di utilizzare modelli di design o di non utilizzare affatto modelli. Il vero è che la scelta è tra l'utilizzo di un modello stabilito o uno schema fatto in casa. A volte il tuo design sarà migliore dell'approccio consigliato, ma ... di solito non lo sarà. Perché passare attraverso tutto il lavoro di risoluzione di un problema che è già stato risolto bene. La tua versione semi-cotta non sarà quasi mai così buona, e devi sprecare tutto quel brainergy a pensarci.

Nella mia esperienza, veloce & sporco è un ossimoro. Ogni volta che puoi risparmiare risparmiando sul design è quasi sempre consumato da un debugging extra.

Non impegnarti in una scadenza che non ti dia abbastanza tempo per fare le cose nel modo giusto. Alla fine devi restituire il debito tecnico, e più codice hai a disposizione prima di iniziare a rielaborare le cose in un design sano, più difficile sarà. Ciò significa anche un sovraccarico di lavoro e programmazione.

L'elenco degli schemi di progettazione è molto lungo (alle persone piace dare nomi alle cose). Anche se non stai pensando "Ok, qui sto usando _ qui", probabilmente la cosa che stai facendo è uno schema che qualcuno ha chiamato. Più programmi, più avrai un'idea su come fare qualcosa e meno dovrai preoccuparti di quali pattern stai usando.

I think once your first version is released and you have plenty of time for the next release, than you can think of improving code quality and manageability with design patterns.

Condivido una situazione simile. Per il mantenimento delle applicazioni, potrebbe essere necessario un ampio refactoring per rendere utile lo schema di progettazione. Se c'è un grande tempo di inattività dietro l'angolo, allora è meglio rimandare finché non hai il tempo di risolvere il problema.

Specialmente se il cliente sta richiedendo un prodotto ieri. Il triangolo di qualità del software esiste indipendentemente dal fatto che tu lo riconosca o ne sia consapevole. "Riuscire a farlo bene la prima volta" richiede spesso una pianificazione anticipata, compresi buoni requisiti e creep di bassa portata. Ciò significa che il cliente deve essere disposto a partecipare attivamente al successo condiviso del progetto.

Ricorda inoltre che OO 101 richiede uno per costruire una sezione finché non è completa. POI refactor, altrimenti stai solo facendo girare le ruote.

Non è più un lavoro e un sovraccarico per farlo bene la prima volta.

Se non è rotto, è probabile che non venga risolto. E non proprio non significa necessariamente rotto. Ci sarà sempre qualcos'altro che deve essere fatto. Quindi dedicheresti molto più tempo a supportarlo e meno tempo a correggerlo o creare qualcosa di nuovo.

Non solo farlo correttamente non richiede più tempo che sbagliarlo. Potrebbe sembrare a breve termine come se non si rispettassero le scadenze o le pietre miliari dell'arbitro. Ma alla fine tutto si concentra in circa lo stesso tempo. Ma la qualità della prima versione di QA supererà di gran lunga la prima versione di qa del sedile di costruzione dei pantaloni. Ciò ridurrà la rilavorazione prima del rilascio. Alla fine, fare bene non è solo un pareggio, vince ogni volta.

È probabile che, se ci vuole più tempo per implementare un modello di progettazione, il pattern che stai tentando di utilizzare non è adatto al problema che stai cercando di risolvere. Non si ottengono "punti bonus" nella prossima revisione del codice per l'implementazione di un nuovo modello, il punto è quello di essere in grado di identificare più facilmente i modi comprovati di risolvere problemi comuni. I modelli di progettazione sono un modo in cui le persone condividono un approccio a questi problemi e possono parlarne in termini comuni.

È molto probabile che stiate già usando schemi di progettazione, sono solo una classificazione formale per concetti architettonici ricorrenti.

Per usare un'analogia costruttiva - dove potresti riferirti a una certa parte del tuo edificio come "la parte che trattiene la pioggia e il calore", qualcuno esperto nell'edilizia chiamerebbe quella parte "il tetto". Non c'è alcun svantaggio che io possa vedere nell'implementare un "tetto" su una casa anziché implementare una "parte che trattiene la pioggia e il calore"

Il sovraccarico principale è capire quali sono i modelli di design adatti, dato che sono spesso piuttosto astratti se visti fuori dal contesto. Quasi certamente stai usando Facciata / Fabbrica a meno che tu non stia scrivendo procedurale. Ho trovato l'Observer, la Strategia e la Fabbrica il più facile da far girare la testa all'inizio.

Come altri hanno notato, farlo bene la prima volta è ovviamente più economico. Ma vorrei anche sottolineare che qualsiasi costrutto di programmazione cade da qualche parte sullo spettro del pattern pattern-anti. Stai implementando qualcosa in modo ordinato o no; Il codice infestato 'goto' sta seguendo uno schema, è solo qualcosa che è stato riconosciuto all'inizio come potenzialmente dannoso. Ma si noti che tutto il codice si riduce a salti e diramazioni a un certo punto del ciclo di compilazione. Non c'è nulla di intrinsecamente sbagliato nel saltare: finisce per rendere i progetti più grandi più difficili da capire.

È facile essere fuorviati da schemi che sembrano banali per casi di uso semplice. Non appena inizi a richiedere più flessibilità, la maggior parte dei modelli fragili degenererà in anti-schemi. Quindi la mia regola è scrivere solo codice che riesco a capire e avere una ragionevole possibilità di debugging. Se decido di applicare ciecamente un modello intelligente, devo essere altrettanto intelligente del codice del pattern per poterlo fare il debug. Quindi, la chiave è assicurarsi che tu stia isolando e utilizzando schemi specifici per il tuo problema direttamente, che ti stai avvicinando al problema al livello appropriato di astrazione e che puoi capire ed eseguire il debug di ogni riga del tuo codice.

Una chiave qui sta colpendo il giusto equilibrio tra i requisiti a breve e lungo termine. Tieni presente che scrivere velocemente un buon codice è qualcosa che a partire da modelli ben compresi può certamente aiutare - il codice degli spaghetti potrebbe sembrare più veloce, soprattutto all'inizio. Ma vedrai rapidamente i limiti degli anti-pattern in qualsiasi progetto più grande, dove la scomposizione, la modularità, ecc. Diventano incredibilmente importanti.

Sto andando controcorrente e dico che possono aiutare ma molto spesso fanno male quando nelle circostanze che descrivi.

Aiutano SE tu ne hai molta familiarità E (hai una buona copertura di prova di tutte le parti che saranno efficaci O questa è la codifica del campo verde).

Ma, davvero, se stai facendo questa domanda, allora anche tu A. Non usare gli schemi come un modo naturale di fare le cose (perché se lo facessi non penseresti a chiederlo, lo faresti semplicemente senza pensare) O B. Il codice è così incompatibile con l'implementazione del pattern nella quantità assegnata che è semplicemente irrealistico usare il pattern.

No. Sembra che ci sia bisogno di tempo per applicare le migliori pratiche (Design Patterns, M.V.C., whetever) a un problema, e non è che io o altri sviluppatori non conosciamo bene i Patterns Design.

Alcune di queste buone pratiche possono essere applicate anche se sei di fretta, ma un buon sistema richiede tempo per progettare.