Essas siglas e acrônimos se espalham com muita facilidade por serem projetados para serem lembrados. Alguns soam bobos por forçarem muito a barra para gerar o encaixe do do explicação com o acrônimo. Além disso, alguns deles são simplesmente ideias gerais e outros são claros e definem pontos específicos na construção de projetos. Assim o artigo Princípios e Acrônimos: SPOT, DRY, AHA, etc. vai dar uma pequena visão geral sobre os mais utilizados hoje em dia. No mais, acho que eles nem sempre têm relação específica com o desenvolvimento, mas com a definição de projetos ou até mais longe: na condução das ações na vida como um todo.

KISS – Keep It Simple, Stupid

Para começar, o acrônimo KISS (Keep it simple, stupid) é amplamente conhecido e debochado. Assim esse princípio de design sugere que se deve fazer simples antes de complicar. Portanto na programação em si a ideia é que o código deve ser simples e direto ao ponto, sem inserir complexidade desnecessária no momento errado: Muito menos fazer overengineering na construção das aplicações. Em resumo, o código deve ser fácil de entender e manter, mesmo para aqueles que não o escreveram originalmente.

DRY – Don’t Repeat Yourself

Além dele, o DRY (Don’t repeat yourself) é outro princípio de design de software. Ele diz que você não deve criar lógicas repetitivas ou informações redundantes. Tenho alguns amigos que dizem assim: “eu sou preguiçoso, por isso quero fazer uma vez só e direito”. Acho que é mais ou menos esse o espírito.

WET – Write Everything Twice

Por outro lado o WET é uma espécie de contra padrão aqui no artigo Princípios e Acrônimos: SPOT, DRY, AHA, etc. Portanto o conceito é ‘escreva tudo duas vezes’. Assim ele se vale da ideia de que é mais rápido escrever duas vezes do que gastar esforço gerando abstrações que geram complexidade ao software. Desse modo esse princípio é bastante questionável e de maneira geral não é uma recomendação. Porém do ponto de vista restrito do desenvolvimento ele é um deboche ao DRY. (Dry em inglês pode significar seco, enquanto Wet pode significar molhado).

YAGNI – You Ain’t Gonna Need It

Já o YAGNI é um acrônimo para “You Ain’t Gonna Need It” (Você Não Vai Precisar Disso). Esse princípio diz que você só deve desenvolver uma coisa se ela de fato tiver uma aplicação real e no momento em questão. Ou seja, se ninguém pediu, não faça por sua própria conta. Isso é uma questão ainda mais importante quando vemos programadores que acham que entendem do negócio e fazem funcionalidades que não representam um caso de uso real. O grande foco desse princípio é evitar a escrita de código desnecessário que gera complexidade acidental.

AHA – Avoid Hasty Abstractions

Já esse princípio de design chama atenção para evitar complexidades associadas a abstrações prematuras. A ideia é tentar fazer estruturas mais palpáveis e de fácil compreenção e só abstrair quando for a melhor opção e não quando for a primeira opção. Mais uma vez um padrão reforça a necessidade de não gerar complexidade no momento incorreto.

SPOT – Single Point Of Truth

O conceito de SPOT é normalmente associado à gestão de dados ao invés do desenvolvimento dos sistemas. Ele pode ser chamado de ‘Single point of truth’ ou ‘Single source of truth’ indicando que deve haver um ponto central e confiável para o dado que está sendo tratado. Isso porque quando há vários pontos com o mesmo dado ou com desdobramentos do dado nem sempre é garantido que ele esteja coerente com a realidade. Pontanto um ponto base pode reduzir a complexidade e aumentar a confiabilidade de um sistema.

SOLID

Para fechar vamos comentar sobre o SOLID, princípio de design mais conhecido da lista. Esse foi cunhado pelo Uncle Bob em ~2000. O conceito define um conjunto de práticas associadas a programação para que o software seja mais flexível, escalável e manutenível. Utiliza-los é considerado uma boa prática; e eles podem ser aplicados a vários níveis do design de software, desde a arquitetura até a codificação individual. Veja também DDD Estratégico.

S (Single Responsibility Principle)

Princípio da Responsabilidade Única, que afirma que uma classe deve ter apenas uma única responsabilidade, ou seja, ela deve ter apenas uma razão para mudar.

O (Open/Closed Principle)

Princípio Aberto/Fechado, que afirma que as classes devem estar abertas para extensão, mas fechadas para modificação.

L (Liskov Substitution Principle)

Princípio da Substituição de Liskov, que afirma que um objeto de uma classe derivada deve ser substituível por um objeto de sua classe base sem quebrar a integridade do sistema.

I (Interface Segregation Principle)

Princípio da Segregação de Interfaces, que afirma que uma classe não deve ser forçada a implementar interfaces que não usa. Em vez disso, ela deve implementar apenas as interfaces que são relevantes para sua funcionalidade.

D (Dependency Inversion Principle)

Princípio da Inversão de Dependência, que afirma que os módulos de alto nível não devem depender de módulos de baixo nível. Em vez disso, ambos devem depender de abstrações.

Conclusão de Princípios e Acrônimos: SPOT, DRY, AHA, etc.

É fácil notar que a maior parte desses princípios têm um objetivo específico: fazer a manutenção da complexidade. Alguns deles indicam que não deve-se gerar complexidade, outros focam nas abstrações, outros de maneira jocosa jogam na cara que é você o culpado pela complexidade acidental gerada. De modo geral o artigo Princípios e Acrônimos: SPOT, DRY, AHA, etc. tentou explicar esses modelos e de que maneira podem ser úteis.