DRY, YAGNI e KISS

Introdução

Essa é a segunda postagem correspondente à minha jornada para ser um desenvolvedor melhor. Novamente, gostaria de deixar claro que estou seguindo o excelentíssimo Web Developer Roadmap 2021, criado por Kamran Ahmed, como base para os meus estudos. Caso você queira ler a a minha primeira postagem, na qual eu resumi um pouco sobre o SOLID, clique aqui.

Enfim, vamos falar um pouquinho sobre DRY, YAGNI e KISS!!

DRY (Don’t Repeat Yourself — Não se repita)

“De tanto voltar ao seu ponto de partida, percebi que o poço profundo criado pela repetição transformou-se em mina de lamentações.” — Balsa Melo

A definição formal desse princípio, cunhada por Andy Hunt e Dave Thomas no excelentíssimo “O Programador Pragmático: de aprendiz a mestre”, diz que:

“Cada parte do conhecimento deve ter uma representação única, não ambígua e definitiva dentro do sistema.”

Contudo, não se engane em achar que este princípio se trata apenas de “não tenha código duplicado”, ele vai muito além disso. O próprio Andy Hunt enfatizou em uma discussão no wiki do repositório de padrões de Portland, o seguinte:

“A duplicação e a possibilidade de contradições podem surgir em qualquer lugar: na arquitetura, em requisitos, código e até mesmo na documentação. Os efeitos podem variar desde falhas de implementação de código, à confusão dos desenvolvedores; até a falha completa do sistema.”

Mas é claro, por mais que o conceito por trás do DRY seja bastante amplo, ainda assim vale falarmos um pouco do efeito da não aplicação desse princípio em nossos códigos:

• Aumento da possibilidade de bugs, já que quando alguma mudança ocorre no sistema, talvez não tenhamos a garantia de que todas as instâncias repetidas também serão atualizadas;
• A duplicação também pode gerar um aumento no tempo e esforço gasto na realização de manutenções, dificultar refatorações e criar possíveis contradições lógicas;
• Dependendo da linguagem, pode acarretar até em problemas no desempenho da aplicação;

Uma última ressalva, é que caso seus testes, builds e deploys ainda sejam manuais, repetitivos e custosos em termos de tempo e esforço, talvez seja a hora de você pensar um pouco em automação. Duplicação na lógica deve ser eliminada via abstração; a duplicação no processo deve ser eliminada via automação.

YAGNI (You Aren’t Gonna Need It — Você não vai precisar disso)

“Tudo é caro demais quando não é necessário.” — James Joyce

YAGNI é um mantra pregado pelo eXtreme Programming (XP), onde resumidamente se diz que não devemos adicionar novas funcionalidades ao software a não ser que realmente seja necessário. Evitando essas “previsões”, você economiza tempo, pois evitará escrever código que não vai precisar no momento, e também, deixa seu código limpo, pois evitará poluir ele com “palpites” que acabam, na maioria das vezes, dificultando o entendimento do mesmo.

Contudo, uma ressalva foi feita pelo todo-poderoso Martin Fowler em uma excelente publicação sobre o YAGNI, na qual ele diz:

“Agora entendemos por que o YAGNI é importante, podemos ‘cavar’ uma confusão comum sobre o ele. Esse princípio se aplica apenas aos recursos incorporados ao software para oferecer suporte a um recurso presuntivo; não se aplica ao esforço para facilitar a modificação do software. YAGNI é apenas uma estratégia viável se o código for fácil de alterar, portanto, gastar esforços na refatoração não é uma violação deste princípio porque a refatoração torna o código mais maleável.”

KISS (Keep It Simple, Stupid — Mantenha simples, estúpido)

“A simplicidade é o último grau de sofisticação” — Leonardo Da Vinci

Um dos meus professores durante a minha graduação me agraciou com uma excelente definição sobre esse princípio. Em uma de suas aulas ele disse que o acrônimo KISS significava Kids In Satan’s Service (Crianças a serviço de Satanás), porquê códigos mal escritos, e consequentemente, difíceis de entender, com certeza eram feitos por algum novato/principiante a mando de Satã (Risos). É claro, por mais que essa seja uma definição deveras cômica, ela ainda não nos trás a real essência desse princípio, que é basicamente, ser simples. Toda e qualquer complexidade desnecessária em um projeto, independente da área, deve ser descartada.

O princípio KISS é usado em um variedade de campos, como design de produto, design de interface, propaganda, desenvolvimento de software, etc. Mas o que pouca gente sabe é que este termo foi utilizado pela primeira vez na Marinha dos EUA, cuja a autoria foi creditada a Kelly Johnson, que era o engenheiro principal no Lockheed Skunk Works. Johnson disse o seguinte aos projetistas da Lockheed:

“Designs devem ser simples o suficiente para serem reparados por um homem em uma situação de combate com apenas alguns treinamentos mecânicos básicos e ferramentas simples.”

Você provavelmente consegue assimilar essa situação descrita por Kelly Johnson com um prazo de entrega curto e um chefe bastante rigoroso. Pois é, meu amigo.. Mantenha as coisas simples.

Conclusão

DRY, YAGNI e KISS são três principios essenciais para qualquer desenvolvedor, e me atrevo a dizer que talvez você consiga aplicá-los até mesmo em outras situações da sua vida, é claro, usando o bom senso.

Essa postagem é um resumão sobre os meus estudos acerca desses princípios, o que vem a ser, talvez, até um pouco superficial demais, caso você esteja querendo se aprofundar nesses temas. Por isso, recomendo que você continue seus estudos, continue procurando conteúdo sobre esses princípios, porque eu tenho certeza que dominá-los e aplicá-los em sua profissão farão de você um desenvolvedor MUITO melhor.

Obrigado pela leitura e até a próxima! 😉