Você conseguiu implementar padrões de design em prazos apertados?

Pergunto-me, em prazos apertados, quem tem tempo para implementar padrões de design? É muito mais trabalho e sobrecarga de programação para acertar na primeira vez e dentro do prazo. Sei que possui vantagens a longo prazo, mas você conseguiu implementar corretamente qualquer padrão de design quando o cliente está sentado de cabeça para baixo e a pressão está aumentando.

Acho que depois que sua primeira versão for lançada e você tiver bastante tempo para a próxima versão, poderá pensar em melhorar a qualidade e a gerenciabilidade do código com os padrões de design.

É muito mais trabalho e sobrecarga de programação para acertar na primeira vez e dentro do prazo.

Isso é falso.

Sem o benefício de alguém já ter pensado no padrão de design, explicado e documentado, seria duas vezes mais difícil.

Um padrão de design simplifica todo o pensamento, a reflexão e a decisão.

Você não precisa inventar algo novo. Você pode usar algo que já é bem compreendido por você e pelos outros.

Os padrões de design permitem que você pense menos. Esse é realmente o ponto inteiro. Há um pouco de uma dicotemia falsa implícita na pergunta. Isso sugere que você use padrões de design ou não use nenhum padrão. A verdadeira opção é entre usar um padrão estabelecido ou um padrão caseiro. Às vezes, seu design será melhor do que a abordagem recomendada, mas ... geralmente não será. Por que fazer todo o trabalho de resolver um problema que já foi resolvido bem? Sua própria versão semi-assada dificilmente será tão boa, e você terá que desperdiçar toda essa inteligência imaginando isso.

Na minha experiência, quick & dirty é um oxímoro. Sempre que você economiza economizando no design, quase sempre é consumido por depuração extra.

Não se comprometa com um prazo que não lhe dê tempo suficiente para fazer as coisas corretamente. Você precisa pagar a dívida técnica eventualmente, e quanto mais código tiver antes de começar a redefinir as coisas em um design sensato, mais difícil será. Isso significa ainda mais trabalho e sobrecarga de programação.

A lista de padrões de design é muito longa (as pessoas gostam de dar nomes às coisas). Mesmo se você não estiver pensando em "Ok, aqui estou usando _ aqui", o que você provavelmente está fazendo é um padrão que alguém nomeou. Quanto mais você programar, mais terá uma idéia de como fazer algo e menos terá que se preocupar com os padrões que está usando.

Acho que depois que sua primeira versão for lançada e você tiver bastante tempo para a próxima versão, poderá pensar em melhorar a qualidade e a gerenciabilidade do código com os padrões de design.

Eu compartilho uma situação semelhante. Para a manutenção de aplicativos, pode haver uma refatoração extensiva necessária para tornar o padrão de design valioso. Se houver um grande tempo de inatividade ao virar da esquina, é melhor adiar até que você tenha tempo para corrigir o problema.

Especialmente se o cliente está exigindo um produto ontem. O triângulo da qualidade do software existe se você o reconhece ou está ciente. "Fazer a correção da primeira vez" geralmente exige um planejamento inicial pesado, incluindo bons requisitos e fluência de escopo baixo. Isso significa que o cliente deve estar disposto a participar ativamente do sucesso compartilhado do projeto.

Lembre-se também de que o OO 101 exige que você construa uma seção até que os requisitos sejam concluídos. ENTÃO refatorar, caso contrário você está apenas girando suas rodas.

Não é mais trabalho e despesas gerais acertar na primeira vez.

Se não houver chances quebradas, não será corrigido. E não é certo, não significa necessariamente quebrado. Sempre haverá algo mais que precisa ser feito. Assim, você gastará muito mais tempo apoiando-o e menos tempo capaz de corrigi-lo ou criar algo novo.

Não apenas que fazer certo não leva mais tempo do que fazer errado. Pode aparecer no curto prazo, como se você não estivesse cumprindo prazos ou marcos arbitrários. Mas, no final, tudo se reúne na mesma quantidade de tempo. Mas a qualidade do primeiro QA Release ultrapassará em muito o primeiro qa do assento da calça. Isso reduzirá o retrabalho antes do lançamento. No final, fazer o certo não apenas empata, vence sempre.

As chances são de que, se você demorar mais para implementar um padrão de design, o padrão que você está tentando usar não é adequado para o problema que está tentando resolver. Você não recebe "pontos de bônus" na sua próxima revisão de código para implementar um novo padrão. O ponto é poder identificar com mais facilidade maneiras comprovadas de resolver problemas comuns. Os padrões de design são uma maneira de as pessoas compartilharem uma abordagem desses problemas e poderem falar sobre isso em termos comuns.

É muito provável que você já esteja usando padrões de design, eles são apenas uma classificação formal para conceitos de arquitetura comumente recorrentes.

Para usar uma analogia de construção - em que você pode se referir a uma certa parte do seu prédio como "a parte que mantém a chuva e o calor", alguém versado no edifício chamaria essa parte de "teto". Não há desvantagem que eu possa ver na implementação de um "telhado" em uma casa, em vez de implementar uma "parte que mantém a chuva fora e o calor"

A principal sobrecarga é descobrir quais padrões de design se encaixam onde, pois geralmente são bastante abstratos quando vistos fora do contexto. Você certamente está usando Fachada / Fábrica, a menos que esteja escrevendo procedimentos. Achei o Observer, Strategy e Factory o mais fácil para começar a pensar.

Como outros observaram, acertar na primeira vez é obviamente mais barato. Mas eu também apontaria que qualquer construto de programação cai em algum lugar do espectro do padrão anti-padrão. Você está implementando algo de maneira ordenada ou não; O código infestado 'goto' segue um padrão, é apenas algo que foi reconhecido desde o início como potencialmente prejudicial. Mas observe que todo o código se resume a saltos e ramificações em algum momento do ciclo de compilação. Não há nada de errado em pular: isso acaba dificultando a compreensão de projetos maiores.

É fácil ser enganado por padrões que parecem triviais para casos de uso simples. Assim que você começar a precisar de mais flexibilidade, a maioria dos padrões quebradiços degenerará em antipadrões. Portanto, minha regra é escrever apenas código que eu possa entender e ter uma chance razoável de depuração. Se eu decidir aplicar um padrão inteligente às cegas, tenho que ser pelo menos tão inteligente quanto o código do padrão para depurá-lo. Portanto, a chave é apenas garantir que você isole e utilize padrões que se apliquem diretamente diretamente ao seu problema, que esteja abordando o problema no nível adequado de abstração e que possa entender e depurar todas as linhas do seu código.

Uma chave aqui é encontrar o equilíbrio certo entre os requisitos de curto e longo prazo. Lembre-se de que escrever um bom código rapidamente é algo que certamente pode ajudar a partir de padrões bem compreendidos - o código de espaguete pode parecer mais rápido, especialmente no início. Mas você verá rapidamente as limitações dos antipadrões em qualquer projeto maior, onde a decomposição, a modularidade etc. se tornam incrivelmente importantes.

Eu vou contra a corrente e digo que eles podem ajudar, mas muitas vezes machucam quando, nas circunstâncias que você descreve.

Eles ajudam SE você está familiarizado com eles E (você tem uma boa cobertura de teste de todas as partes que serão eficazes OU essa é a codificação em campo verde).

Mas, realmente, se você está fazendo esta pergunta, então você ou A. Não use os padrões como uma maneira natural de fazer as coisas (porque se você pensasse que não pensaria em perguntar, faria apenas sem pensar) OU B. O código é tão incompatível com a implementação do padrão na quantidade alocada que é simplesmente irreal usar o padrão.

Não. Parece levar tempo para aplicar as melhores práticas (Design Patterns, MVC, qualquer que seja) a um problema, e não é que eu ou outros desenvolvedores não conheçamos bem os Design Patterns.

Algumas dessas boas práticas podem ser aplicadas mesmo se você estiver com pressa, mas, um bom sistema, leva tempo para projetar.