O problema da super-engenharia (YAGNI)
Evite tornar o código mais flexível ou sofisticado do que o necessário: Embora alguns programadores possam argumentar que é melhor projetar um sistema mais flexível ou sofisticado para acomodar futuras necessidades, isso pode levar ao desperdício de tempo e dinheiro se as previsões estiverem erradas. É importante encontrar um equilíbrio entre flexibilidade e simplicidade.
Evite superengenharia: Projetar um código excessivamente flexível ou desnecessariamente sofisticado pode resultar em um aumento desnecessário da complexidade. Isso pode levar a problemas, como a acumulação de código não utilizado, dificuldades para os programadores trabalharem em áreas específicas do sistema e uma curva de aprendizado mais longa para novos membros da equipe.
A superengenharia afeta a produtividade: A herança de um projeto superprojetado pode exigir que os programadores gastem tempo extra para entender o código existente antes de poderem expandi-lo ou mantê-lo adequadamente. Isso pode levar a um declínio na produtividade da equipe.
Esteja ciente da engenharia excessiva: Muitos programadores podem não estar conscientes de que estão fazendo superengenharia. É importante reconhecer os sinais e os impactos negativos que ela pode ter na produtividade e eficiência da equipe.
Equilíbrio entre simplicidade e qualidade: Embora seja importante evitar um design ruim, também é crucial evitar excessos na engenharia. A abordagem inicial com padrões pode ser atraente, mas é necessário encontrar um equilíbrio para evitar complicações desnecessárias no código.
##
Problema de pensar demia snos padroes de projeto
Mas com o tempo, o poder dos padrões me levou a perder de vista maneiras mais simples de escrever código. Depois de aprender que havia duas ou três maneiras diferentes de fazer um cálculo, eu imediatamente corria para implementar o padrão Strategy, quando, na verdade, uma expressão condicional simples teria sido mais fácil e rápida de programar – uma solução perfeitamente suficiente.
O que devemos mantesr em mente
É concentrar em escrever códigos pequenos, simples e compreensíveis ao inveś de meter um padrâo de projeto a cada segundo.
Além disso, seguindo o YAGNI, o padrão de proejto deixa o código mais flexiviel, mas, será mesmoo que naquele ponto voce precisa ser tão FECHADO PARA ALTERAÇAO E ABERTO APRA EXTENSAO. Pois muitas vezes implemtntar essa coisas vai gera muito mais codigo do qu eum simples if faria.. Eu estava em uma encruzilhada: trabalhei duro para aprender padrões para me tornar um designer de software melhor, mas agora precisava relaxar minha confiança neles para me tornar realmente melhor.
A subengenharia (escreve rapido sem pensar em degin nenhum) contínua leva ao ritmo “rápido, lento, lento” do desenvolvimento de software, que é mais ou menos assim.
Você entrega rapidamente a versão 1.0 de um sistema com código indesejado.
Você entrega a versão 2.0 do sistema e o código indesejado o atrasa.
Ao tentar entregar lançamentos futuros, você vai cada vez mais devagar à medida que o código lixo se multiplica, até que as pessoas percam a fé no sistema, nos programadores e até mesmo no processo que colocou todos nessa posição.
Em algum momento durante ou após a versão 4.0, você percebe que não pode vencer. Você começa a explorar a opção de uma reescrita total.
Esse tipo de experiência é muito comum em nosso setor. É caro e torna as organizações muito menos competitivas do que poderiam ser. Felizmente, existe uma maneira melhor.
Desenvolvimento Orientado a Testes (TDD) e Refatoração Contínua são práticas excelentes que melhoram a forma como o software é construído.
TDD e Refatoração Contínua permitem a evolução eficiente do código de trabalho, transformando a programação em um diálogo através de um ciclo de perguntas, respostas, refinamento e repetição.
O uso do TDD ajuda a evitar gastar muito tempo pensando em um design complexo para o sistema, permitindo que o desenvolvedor faça o comportamento básico funcionar corretamente antes de refatorar e evoluir para um nível mais sofisticado.
O mantra do TDD e Refatoração Contínua é “vermelho, verde, refatorar”, onde o desenvolvedor cria um teste que falha (vermelho), programa o código para fazê-lo passar (verde) e, em seguida, melhora o design do código (refatorar).
TDD e Refatoração Contínua proporcionam um estilo de programação enxuto, iterativo e disciplinado, maximizando o foco, a produtividade e o relaxamento.
Dominar o TDD e a Refatoração Contínua requer prática, mas uma vez aprendidos, esses métodos ajudam a manter a contagem de defeitos baixa, refatorar com confiança, produzir código mais simples e melhor, e programar sem estresse.
Recomenda-se estudar livros como “Desenvolvimento Orientado a Testes” de Kent Beck e “Refatoração” de Martin Fowler, assim como explorar exemplos e práticas de refatoração.
Em vários projetos, observei o que e como meus colegas e eu refatoramos. Embora usemos muitas das refatorações descritas em Refactoring (Martin Folwer), também encontramos lugares onde os padrões nos ajudam a melhorar nossos designs Nessas ocasiões, refatoramos para ou em direção a padrões, tomando cuidado para não produzir soluções excessivamente flexíveis ou sofisticadas desnecessariamente..
Quando explorei as motivações para aplicar refatorações direcionadas a padrões, descobri que elas são idênticas às motivações gerais para implementar refatorações de baixo nível: reduzir ou remover a duplicação, simplificar o que é complicado e tornar o código melhor para comunicar sua intenção.
Essa motivação pode ser facilmente perdida se você estudar apenas uma parte de um padrão de projeto. Por exemplo, cada padrão em Design Patterns (GOF) inclui uma seção conhecida como Intenção. Os autores de Design Patterns descrevem essa Intenção da seguinte forma: “Uma breve declaração que responde às seguintes perguntas: O que o padrão de projeto faz? Qual é sua lógica e intenção? Que questões ou problemas específicos de projeto ele aborda?” Design Patterns (GOF). Apesar dessa descrição, as seções Intent para muitos padrões de projeto apenas indicam o problema principal que o padrão resolve. Em vez disso, mais foco é colocado no que o padrão faz. Aqui estão dois exemplos.
Intenção do Template Method
Defina o esqueleto de um algoritmo em uma operação, adiando algumas etapas para subclasses. O Template Method permite que as subclasses redefinam certas etapas de um algoritmo sem alterar a estrutura do algoritmo. Design Patterns (GOF)
Intenção do State
Permite que um objeto altere seu comportamento quando seu estado interno muda. O objeto parecerá mudar de classe. Design Patterns (GOF)
Essas descrições de intenção não dizem que um Tempalte Method ajuda a reduzir ou remover código duplicado em métodos semelhantes de subclasses em uma hierarquia ou que State ajuda a simplificar a lógica complexa de mudança de estado condicional. Se os programadores estudarem todas as seções de um padrão de projeto, particularmente a seção Aplicabilidade, eles aprenderão sobre os problemas que o padrão aborda ,…, mas nem sepre ficará claro que o DesignPatrernn pode ser usada para melhorar o código já existetnete.
No entanto, ao usar o design Patterns o projeto, muitos programadores, inclusive eu, leram a seção Intent de um padrão para ver se o padrão poderia fornecer um bom ajuste para uma determinada situação. Este método de escolha de um padrão não funciona tão bem quanto um método que ajuda você a combinar um problema de design com os problemas abordados por um padrão. Por que? Porque os padrões existem para resolver problemas, e saber se eles realmente podem ajudar em uma determinada situação envolve entender quais problemas eles ajudam a resolver.
A literatura de refatoração tende a se concentrar mais em problemas de design específicos do que a literatura de padrões. Se você estudar a primeira página de Refactoring (Martin Folwer), verá o tipo de problema que a refatoração ajuda a resolver.
O catálogo de refatorações direcionadas a padrões apresentado neste livro, que é uma continuação direta do trabalho iniciado em Refactoring (Martin Folwer), destina-se a ajudá-lo a ver quais tipos de problemas específicos os padrões ajudam a resolver.
Enquanto este livro preenche a lacuna entre padrões e refatoração, a conexão entre os dois foi observada pelo autores de Design Patterns (GOF) conclusão de seu grande livro:
Nossos padrões de projeto capturam muitas das estruturas resultantes da refatoração. . . . Os padrões de design, portanto, fornecem alvos para suas refatorações. Livro Design Patterns (GOF)
Martin Fowler faz uma observação semelhante perto do início de Reestruturação:
Existe uma relação natural entre padrões e refatorações. Os padrões estão onde você quer estar; refatorações são maneiras de chegar lá de outro lugar. Design Patterns (GOF)
Se você deseja obter o máximo dos padrões, deve fazer a mesma coisa: veja os padrões no contexto da refatoração, não apenas comoelementos reutilizáveis que existem fora da refatoração. Esta é minha principal razão para produzir um catálogo de refatorações direcionadas a padrões.
Aprendendo a evoluir seus projetos, você pode se tornar um designerde software melhor e reduzir a quantidade de trabalho que você faz na engenharia. TDD e refatoração contínua são a chave práticas de design evolutivo. Instile refatorações direcionadas a padrões em seu conhecimento de como refatorar e você se sentirá ainda mais bem equipado para desenvolver grandes designs.