Princípios do SOLID vs YAGNI

Quando os princípios do SOLID se tornam YAGNI?

Como programadores, fazemos trocas o tempo todo, entre complexidade, manutenção, tempo para construir e assim por diante. Entre outras, duas das diretrizes mais inteligentes para fazer escolhas estão em minha mente os princípios do SOLID e o YAGNI. Se você não precisar; não construa e mantenha-o limpo.

Agora, por exemplo, quando assisto a série dimecast no SOLID , vejo que ele começa como um programa bastante simples e acaba sendo um programa bastante complexo (final, a complexidade sim também está nos olhos de quem vê), mas ainda faz me pergunto: quando os princípios do SOLID se transformam em algo que você não precisa? Todos os princípios sólidos são maneiras de trabalhar que permitem o uso para fazer alterações posteriormente. Mas e se o problema a ser resolvido for bem simples e for um aplicativo descartável, e daí? Ou os princípios do SOLID são algo que sempre se aplica?

Conforme solicitado nos comentários:

• Princípios do SOLID
• YAGNI

É sempre difícil julgar uma abordagem com base em um screencast, já que os problemas escolhidos para as demos são geralmente tão pequenos que a aplicação de princípios como o SOLID faz com que pareça que a solução está completamente com excesso de engenharia.

Eu diria que os princípios do SOLID são quase sempre úteis. Depois de se tornar proficiente com eles, usá-los não parece ser algo em que você tenha que pensar deliberadamente. Apenas se torna natural. Eu já vi muitos aplicativos descartáveis ​​descartáveis ​​se tornarem mais do que isso, então agora tenho medo de dizer que vou jogar algo fora, porque você nunca sabe.

A abordagem que eu costumo adotar é que, se estou escrevendo um aplicativo simples para uma tarefa específica, algumas vezes renuncio a princípios de grandes nomes em favor de algumas linhas de código que funcionam. Se eu achar que estou voltando ao aplicativo para fazer mais alterações, levarei um tempo para torná-lo sólido (pelo menos um pouco, pois uma aplicação de 100% dos princípios raramente é viável).

Em aplicativos maiores, começo pequeno e, à medida que o programa evolui, aplico os princípios do SOLID sempre que possível. Dessa forma, não tento projetar a coisa toda de antemão até o último enum. Esse, para mim, é o ponto ideal onde YAGNI e SOLID coexistem.

Pense sobre o problema em primeiro lugar. Se você aplicar cegamente os princípios de YAGNI ou SOLID, poderá se machucar mais tarde. Algo que espero que todos possamos entender é que não existe uma abordagem de design "única" que atenda a todos os problemas. Você pode ver evidências disso quando uma loja vende um chapéu anunciado como "tamanho único", mas não combina com sua cabeça. É muito grande ou muito pequeno.

Em vez disso, é melhor entender os princípios e problemas que o SOLID está tentando resolver; bem como os princípios e problemas que a YAGNI está tentando resolver. Você verá que um se preocupa com a arquitetura do seu aplicativo e o outro se preocupa com o processo de desenvolvimento como um todo. Embora possa haver sobreposição em alguns casos, eles são problemas distintos.

A YAGNI (você não vai precisar disso) quer economizar tempo do desenvolvedor, adicionando fundações de concreto reforçado com aço a uma ponte que se destina apenas a atravessar um riacho de 3 pés de largura quando uma ponte de madeira mais simples bem. Se estamos atravessando um rio de uma milha de largura e precisando suportar vários reboques de tratores, é claro que precisaríamos desse trabalho extra de fundação. Em essência, a YAGNI está dizendo para você olhar para a imagem maior e o design para as necessidades atuais . Está abordando o problema de tornar algo muito complicado, porque estamos antecipando uma série de necessidades potenciais que o cliente ainda não identificou.

O SOLID se preocupa com a forma como garantimos que as peças da ponte se encaixem corretamente e possam ser mantidas com o tempo. Você pode aplicar os princípios do SOLID à ponte de madeira e à ponte de concreto armado de aço.

Em suma, esses dois conceitos não estão necessariamente em conflito entre si. Quando você se deparar com uma situação em que acredita estar, é hora de dar uma olhada no quadro geral. Dependendo da sua conclusão, você pode decidir acabar com uma parte dos princípios do SOLID ou pode realmente precisar.

Os princípios do SOLID não são necessários quando se trata de um aplicativo descartável; caso contrário, eles são sempre necessários.

O SOLID e o YAGNI não estão em desacordo: um bom design de classe facilita a manutenção do aplicativo. YAGNI apenas declara que você não deve adicionar a capacidade de seu aplicativo ser essa monstruosidade configurável que pode fazer tudo sob o sol - a menos que ele realmente precise.

É a diferença entre uma classe Car que possui limites bem definidos (SOLID) e uma classe de carro com capacidade de auto-recuperação (YAGNI) antes que o cliente solicite.

Nada sempre se aplica! Não deixe que os astronautas da arquitetura assustem você! O importante é tentar entender quais problemas esses princípios estão tentando resolver para que você possa tomar uma decisão informada sobre sua aplicação.

Recentemente, eu estava tentando entender quando deveria usar o Princípio de Responsabilidade Única ( eis o que eu criei).

Espero que isto ajude!

Há uma citação atribuída a Einstein (provavelmente uma variação de uma real ):

"Tudo deve ser feito o mais simples possível, mas não mais simples."

E essa é mais ou menos a abordagem adotada quando confrontada com o trade-on do SOLID vs YAGNI: aplique-os alternativamente, porque você nunca sabe se um programa é código 'descartável' ou não. Então, basta adicionar uma camada de sujeira que funcione, depois polir para uma interface mais limpa ... e repetir até convergir para o nível certo de entropia. Esperançosamente.

Existem várias maneiras de criar um programa para um determinado problema; O SOLID é uma tentativa de identificar as propriedades de um bom design. O uso adequado do SOLID deve resultar em um programa mais fácil de raciocinar e modificar.

YAGNI e KISS estão preocupados com o escopo do recurso. Um programa que resolve mais tipos de problemas é mais complexo e abstrato. Se você não precisa dessa generalidade, gastou tempo e esforço criando código mais difícil de entender e manter, mas não oferece valor agregado.

Um programa que foi bem projetado não é necessariamente focado apenas nos recursos necessários. Um programa focado apenas nos recursos necessários não é necessariamente bem projetado. Não há compromisso, apenas dois eixos ortogonais no espaço de tomada de decisão. Um programa ideal é modular e possui apenas recursos essenciais.

Eu acho que você deve iniciar o YAGNI e, sempre que houver necessidade, SOLIDify.

O que eu quero dizer é que o SOLID está lá. Portanto, quando você adiciona uma nova classe, não precisa refatorar, basta alternar uma implementação (por exemplo), bem, na minha opinião, escreva seu código com simplicidade e quando perceber que está mudando coisas - altere-o com o SOLID (isto é, a refatoração temida do SOLID deve salvá-lo - não é tão ruim quando você está apenas começando).

Você não está perdendo tempo, porque teria que fazer o trabalho de qualquer maneira (no início) e onde for necessário, o código é agradável e arrumado.

Eu acho que você poderia chamar de avaliação preguiçosa do SOLID.