Os padrões de design são desaprovados?

Estas são as palavras de alguém que encontrou sucesso e ignora as pessoas que tentam dizer a ele o que fazer no jargão padrão que ele não entende.

Padrões de design e práticas recomendadas não são a mesma coisa. Algumas pessoas pensam que são e fazem com que as pessoas saibam o que estão fazendo. Mesmo que eles não saibam o nome adequado para o que estão fazendo.

Padrões de design existiam antes de terem nomes. Nós lhes demos nomes para facilitar a conversa sobre eles. Um padrão com um nome não é bom. Isso torna uma coisa reconhecível.

Esse cara provavelmente está usando padrões que nenhum de vocês nunca ouviu falar. Tudo bem, até que você precise falar com ele sobre como algo é feito. Ele vai ter que aprender a falar com você ou você vai ter que aprender a falar com ele. Não tem nada a ver com quem está "certo".

Muitos padrões de design, do tipo que você e seu amigo estão descrevendo, são realmente apenas soluções alternativas para deficiências em linguagens de programação . Use uma linguagem de programação mais expressiva e a maior parte da necessidade desses padrões de design desaparece.

Como os padrões de design são necessários para atender a muitos cenários de uso possíveis, eles tendem a ser superestimados. O código superprojetado tem um custo: você precisa lê-lo, entender o que ele faz e entender como ele funciona no contexto de todo o sistema de software. Consequentemente, como em qualquer outra técnica de desenvolvimento de software, você deve avaliar a técnica em relação ao custo de usar a técnica e decidir se os benefícios excedem o custo.

Todas as outras coisas são iguais, menos código é sempre melhor. Já passei por arquiteturas em camadas onde você literalmente precisa fazer de três a seis saltos em vários projetos para encontrar qualquer código que seja interessante, isto é, código que realmente realiza algo diferente de adicionar overhead.

Padrões de software conhecidos supostamente fornecem um vocabulário comum pelo qual você pode comunicar estratégias de design. Infelizmente, muitos desenvolvedores de software não entendem o vocabulário padrão de software o suficiente para aplicá-lo adequadamente a seus problemas de programação. Desenvolvedores inexperientes vêem esses padrões como estando dentro do domínio de especialistas; eles querem ser vistos como especialistas e, assim, tentam aprender e aplicar os padrões cedo demais, antes de estarem prontos. O que eles realmente devem fazer é focar em aprender os fundamentos da programação primeiro, e então tentar resolver o problema que cada padrão se resolve. Se eles fizerem isso, eles estarão em uma posição muito melhor para entender e aplicar os padrões corretamente.

Stackoverflow.SE e Programmers.SE geralmente incentivam as pessoas a seguir as melhores práticas como SOLID, e não padrões de mercado . E acredite ou não, o padrão de fato da indústria é frequentemente a arquitetura "grande bola de lama" - seriamente.

Mas responder diretamente a sua pergunta: o problema com os padrões de design é semelhante ao da herança - muitos desenvolvedores medíocres os usam excessivamente, o que tem um certo risco de criar código overengineered, difícil de manter. Mas a resposta para isso é, certamente, não evitar ou proibir completamente o uso de padrões de design (ou herança), a resposta é aprender a usar essas ferramentas em situações em que elas fazem sentido, e só aí. E isso é totalmente independente de trabalhar "ágil" ou não.

1. Padrões de design são apenas nomes usados para comunicar ideias. Muitas vezes me vi fazendo coisas que depois descobri que tenho um nome. Assim, não há "maneira padrão de design" em oposição a um "modo de padrão não-design".

2. Padrões de design são diretrizes. Como tudo, cada um deles tem vantagens e desvantagens. A chave não é aprender o padrão e aplicá-lo onde ele se encaixa, mas sim entender a ideia do padrão, as vantagens e desvantagens que ele possui e usá-lo para obter inspiração para a solução do seu problema.

3. Todas as melhores práticas e diretrizes podem ser ignoradas se houver um motivo suficiente. Os motivos válidos incluem o tempo de desenvolvimento e as expectativas do aplicativo. Por exemplo, estou ciente de que é ruim codificar valores (exemplo estúpido), mas, para uma prova de conceito, as vantagens podem superar os custos (nesse caso, principalmente o tempo de desenvolvimento). No entanto, se uma decisão como essa for tomada, ela poderá sair pela culatra e, em algum momento, poderá ser necessária uma refatoração.

Para adicionar outra metáfora à sopa, os padrões de design são Clippy, o auxiliar do Microsoft Office. "Você parece estar fazendo a mesma coisa com um monte de coisas. Posso ajudá-lo com isso oferecendo Iterador ou Visitante?"

Uma boa descrição desses padrões indicará quando é útil fazer algo da mesma forma que foi feito muitas vezes antes, quais erros você cometerá na primeira vez em que tentar e quais formas comuns foram encontradas evite esses erros. Então você lê o padrão de design (ou revisa-o da memória) e então continua com seu trabalho. O que você não pode fazer, é apenas usando Clippy e assistentes.

É claro que também é possível que alguém evite um padrão com base no YAGNI, então perceba que precisa dele e procure a solução normal. Isso geralmente (mas nem sempre) é pior do que perceber o requisito desde o início, e é por isso que, mesmo no desenvolvimento ágil, é frustrante quando os requisitos totalmente previsíveis não são descobertos cedo. Eu não posso ter sido o único programador de C ++ que se divertiu muito com o fato de o Java inicialmente ter rejeitado os contêineres genéricos como desnecessariamente complexos, depois os reapareceram mais tarde.

Portanto, é quase um erro evitar escrever um Iterator por princípio porque você prefere evitar padrões de design.

Adding a new field to the UI/database/Data layer takes 2-3 hours to do, where as in his code it takes 30 minutes.

Você não pode realmente argumentar com isso: por essa métrica, seu design é muito melhor que o outro. Se isso é porque ele evitou padrões de design é questionável, acho que é mais provável porque ele considerou os problemas certos do mundo real ao projetá-lo, e com o benefício da experiência é melhor em seu trabalho do que alguém armado apenas com um livro e altos ideais.

Então ele reconheceu que qualquer padrão que requer que você toque muitos pontos diferentes no código para adicionar um campo é um padrão ruim para o trabalho, "facilite a adição de campos", e ele não usou esses padrões. Padrões Arquiteturas em camadas, de fato, podem sofrer a esse respeito, e é errado usar padrões de projeto sem avaliar suas desvantagens.

Em relação a isso, quanto tempo leva para escrever uma nova interface do usuário em seu design e quanto tempo demora em uma arquitetura em camadas? Se o projeto exigisse que ele construísse e implantasse constantemente novas interfaces de usuário em um modelo de dados fixo, em vez de adicionar campos constantemente, esperamos que ele tenha projetado isso. Ou então. Mas, apesar de todos os benefícios, dizer "estamos agilizando", infelizmente, não significa que você nunca terá que fazer outra troca!

Selecionar a partir de um menu de padrões de design certamente pode impedi-lo de pensar nas preocupações mais importantes. Mas reconhecer quando você está escrevendo um Visitante e documentá-lo ou chamá-lo de "Visitante" para ajudar os leitores a obter rapidamente, não atrapalha muito nada. Escrever "isto é um visitante" em vez disso de documentá-lo corretamente é um erro terrível para a razão que seu desenvolvedor sênior dá - programadores não o entenderão. Mesmo os programadores que sabem o que é um visitante precisam de mais informações do que apenas "este é um visitante".

Seu colega parece sofrer da síndrome de NIH ("Não inventado aqui").

É perfeitamente plausível que seu código facilite a inclusão de novos campos: também sou muito mais rápido para atualizar meu código do que o código escrito por outros caras. Mas essa velocidade de curto prazo não diz nada sobre a capacidade de manutenção e a portabilidade do código. Darei a ele o benefício da dúvida: o código existente pode, de fato, estar mal estruturado se tiver seguido um livro de texto mal ou tiver seguido uma boa receita no contexto errado.

Evitar padrões de design é realmente surpreendente. Nos meus últimos 30 anos de codificação e gerenciamento de codificadores, os padrões de design ajudaram a colocar palavras em coisas que foram feitas instintivamente, ajudando a entender mais rapidamente a intenção, as vantagens, inconveniências, riscos, oportunidades e padrões relacionados. Os padrões de design provaram ser aceleradores reais para dominar a complexidade!

• Talvez o seu colega seja realmente muito mais inteligente do que a maioria de nós e ele possa arcar com a sobrecarga de reinventar padrões sem uma diminuição notável da produtividade?

• Os argumentos de que "os programadores não entendem os padrões de design" soam como "não consigo realmente explicar o que estou fazendo". Ou "Eu não quero discutir sobre o meu próprio design". Eu realmente acho que a padronização poderia alavancar o entendimento geral e permitir que colegas menos experientes compartilhem opiniões valiosas. Mas talvez seu colega sênior queira evitar exatamente isso.

As abordagens em camadas provaram ser superiores a outras arquiteturas na maioria dos aplicativos corporativos. Os pacotes líderes de classe mundial são estruturados em torno dessa ideia e superam as arquiteturas artesanais em ordens de magnitude. Martin Fowler apresenta essa abordagem em seu excelente livro sobre "Padrões de arquitetura corporativa". Oh! Desculpe novamente: é sobre padrões comprovados; nenhuma chance na visão do NIH do seu colega; -)

Uma percepção chave que muitas pessoas sentem é que o design de software é contextual. Ela existe para atingir metas de negócios e metas diferentes podem exigir abordagens diferentes. Colocado de forma diferente, não há design que seja sempre melhor, mesmo que sempre exista um melhor design.

Padrões de design são soluções padrão para problemas padrão. No entanto, se você não tiver o problema, resolvê-lo é um desperdício de esforço.

A principal diferença entre o design de software em cascata e ágil é quando as decisões de design são tomadas. Em cascata, reunimos todos os requisitos, identificamos quais padrões de projeto precisamos e só então iniciamos a codificação. Na arquitetura ágil, seguimos o princípio da YAGNI para adiar as decisões de design até o último momento responsável, quando sabemos tanto sobre a escolha quanto possível.

Ou seja, em cascata, os padrões de design tendem a ser aplicados se a necessidade deles for antecipada , em ágil, quando eles são realmente necessários . Como consequência, os projetos ágeis tendem a aplicar padrões de design com menos frequência, porque nem todas as necessidades previstas são reais.

Padrões de design não são realmente chamados de padrões de design porque eles prescrevem o que fazer. Os padrões de design são padrões de design porque descrevem o que foi feito antes. Alguns desenvolvedores ou desenvolvedores projetaram um método que realizou bem uma determinada tarefa e foi capaz de aplicá-la a situações semelhantes com resultados semelhantes. Isso é tudo. Muitos padrões têm pontos strongs e fracos inerentes, e cabe ao desenvolvedor instruído avaliar as necessidades tecnológicas e de negócios para determinar um padrão apropriado a ser aplicado.

Eu geralmente gosto de pensar no mesmo - digamos - "navegação" usando o GPS. Ao aprender 'melhores práticas' e 'padrões de design' - você aprende a seguir a rota de navegação GPS. Mas quando você conhece a área, muitas vezes você aprende que dirigir por uma estrada lateral o levará a áreas problemáticas, chegará mais rápido e / ou melhor. É o mesmo quando se trata dessas coisas - a experiência faz com que você consiga desconstruir sua caixa de ferramentas e usar atalhos.

Aprender padrões de design e aprender "melhores práticas" significa entender melhor a idéia por trás, para que você possa escolher em uma determinada situação. Como as situações da vida real costumam ser mais complexas em comparação com as situações teóricas, muitas vezes você terá restrições e problemas não encontrados nos livros didáticos. Clientes / Clientes querem seu produto rápido e geralmente barato; Você precisa trabalhar com código legado; Você precisa interagir com ferramentas de terceiros que podem muito bem ser caixas pretas e ineficazes; e todo tipo de coisas. Sua situação é específica - as práticas recomendadas e os padrões são mais gerais.

Uma das principais razões pelas quais muitas pessoas em sites como SE lhe dão respostas de 'melhores práticas' e respostas de 'padrão de design' é porque elas estão respondendo em soluções gerais e abstratas e, portanto, ajuda a fornecer uma linguagem comum para resolver um tipo de problemas. E para que você aprenda.

Assim, os padrões de design não são desaprovados nos ambientes de desenvolvimento Agile; desenvolvimento, no entanto, raramente é geral e abstrato o suficiente para encaixar perfeitamente em um padrão e o desenvolvedor (experiente) sabe disso.

Adding a new field to the UI/database/Data layer takes 2-3 hours to do, where as in his code it takes 30 minutes.

Se você deseja "otimizar" um design, precisa dizer o que está tentando otimizar.

Por exemplo, uma bicicleta de corrida é um veículo otimizado ... e um Boeing 747 também é um veículo otimizado ... mas eles são otimizados para um conjunto diferente de requisitos.

A ideia do padrão "MVC", por exemplo, otimiza para coisas como:

• Visualizações diferentes do mesmo modelo (a visualização é independente do modelo)
• Cada camada pode ser desenvolvida separadamente (por exemplo, por equipes diferentes) e testada separadamente (testes de unidade) antes da integração
• etc.

Considerando que seu código pode ser otimizado para outra coisa, por exemplo:

• Linhas mínimas de código
• Fácil para uma pessoa fazer uma alteração que afeta todas as camadas (por não ter camadas realmente distintas)
• etc.

As descrições de padrões começam com uma descrição do problema que o padrão pretende resolver. Se ele acha que é "melhor prática" não usar um padrão específico, (supondo que não seja um padrão estúpido, supondo que seja um padrão útil às vezes), suponho que ele não tenha / vivencie o problema específico que esse padrão reivindica. para resolver, e / ou ele tem um problema diferente (maior ou mais urgente, concorrente) que ele está tentando otimizar em vez disso.

Padrões de design são ferramentas. Como as ferramentas, há duas maneiras de usá-las: a maneira correta e a maneira incorreta. Por exemplo, se eu lhe der uma chave de fenda e um prego, e pedir para você juntar dois pedaços de madeira, você deve me pedir um martelo. Martelos são usados para unhas, enquanto chaves de fenda são usadas para parafusos.

Muitas vezes, um padrão de design é anunciado como o One True Way, que muitas vezes só é verdadeiro quando surgem problemas específicos. Os desenvolvedores juniores costumam ser como crianças quando encontram algo novo para brincar; eles querem aplicar esse padrão de design a tudo . E não há nada inerentemente errado com isso, contanto que eles eventualmente aprendam que o Padrão A se aplica ao Problema B, e o Padrão C se aplica ao Problema D. Assim como você não usa uma chave de fenda para conduzir as unhas, você não usa um determinado padrão apenas porque existe; você usa o padrão porque é a melhor ferramenta (conhecida) para o trabalho.

O outro lado dos padrões são anti-padrões. Coisas que provaram ser sempre ruins, geralmente em termos de tempo de execução ou memória. No entanto, os padrões e os antipadrões não servem para o desenvolvedor que não entende por que eles existem. Os desenvolvedores gostam de pensar que o que estão fazendo é novo e inventivo, mas na maioria das vezes não são. É provável que tenha sido pensado antes. Pessoas antes deles criaram os padrões por causa da experiência.

Naturalmente, os desenvolvedores juniores costumam encontrar novas maneiras de fazer coisas antigas e, às vezes, essas maneiras são melhores. No entanto, muitas vezes acaba sendo um caso do efeito Dunning-Kruger; o desenvolvedor sabe o suficiente para criar um programa funcional, mas não entende suas próprias limitações. A única maneira de superar isso parece ser através da experiência, tanto positiva quanto negativa. Eles ignoram os padrões porque acreditam que são superiores, mas não sabem que, na realidade, 10.000 desenvolvedores já usaram um design específico e o descartaram porque era realmente ruim.

O Agile favorece "fazer as coisas de maneira responsiva" no que diz respeito a se ajustar rapidamente às necessidades crescentes dos clientes. Não favorece padrões de design nem os despreza. Se um padrão é o método mais rápido e mais confiável, o desenvolvedor deve usá-lo. Se um padrão em particular custaria mais tempo do que simplesmente "fazê-lo", usar algo que não é um padrão provavelmente está bem (supondo, é claro, que o desempenho não seja severamente degradado, etc.). Se nenhum padrão conhecido puder ser encontrado, é preferível projetar o seu próprio design ao invés de dizer ao cliente "não". Os clientes, especialmente os clientes pagantes, geralmente estão certos.

Qualquer um que afirme que os padrões são O Caminho, ou afirma que os padrões são O Maldito da Existência, estão errados. Padrões são ferramentas, destinadas a serem aplicadas a situações específicas, e têm diferentes graus de sucesso com base nas circunstâncias. Esta é uma verdade, uma que não depende se você escolheu MVC ou não, se você usa objetos de transferência de dados, ou não, etc. O que importa é implementar código em um período de tempo razoavelmente curto, que funciona razoavelmente bem para os usuários, e é razoavelmente livre de erros lógicos.

Normalmente, os padrões permitirão uma forma coerente de design e funcionarão melhor do que ignorar todos os padrões em favor de escrever 100% de ideias originais, mas você não pode evitar todos os padrões. Por exemplo, se y = x + 5, você realmente escreverá y = x + (5 * 3 + 15/3) / 4, apenas para evitar o padrão de escrita x + 5? Não, você não é. Você vai escrever y = x + 5 e passar para o próximo problema.