O Princípio KISS: Por que o Código Perfeito é o Código Simples (e não o mais complexo)

O que é o Padrão KISS?

KISS é um acrônimo para "Keep It Simple, Stupid" (Mantenha isso simples, estúpido). Apesar do "estúpido" parecer agressivo, é apenas um lembrete enérgico das engenharias tradicionais: sistemas funcionam melhor quando são mantidos simples, em vez de se tornarem complexos.

Na engenharia de software, o KISS combate o nosso maior inimigo oculto: a complexidade acidental.

A complexidade acidental acontece quando o problema de negócio é simples (ex: salvar um dado no banco), mas a solução técnica cria uma teia de abstrações, interfaces, design patterns e heranças desnecessárias. O código perfeito não é aquele que exige um doutorado para ser lido, mas aquele que qualquer desenvolvedor consegue entender, dar manutenção e evoluir sem medo de quebrar tudo.

KISS na Prática com Java

O ecossistema Java evoluiu muito. Se antes precisávamos escrever dezenas de linhas para criar estruturas básicas, hoje a linguagem nos dá ferramentas poderosas para aplicar o KISS de forma nativa. Vamos a dois exemplos práticos de como simplificar as coisas.

Exemplo 1: O Fim do Boilerplate (Classes vs. Records)

Imagine que precisamos criar um DTO (Data Transfer Object) simples para representar os dados de um usuário na nossa aplicação.

Sem KISS (O jeito "clássico" e verboso): No passado, a solução padrão envolveria muito código apenas para carregar dados.

public class UsuarioDTO {
    private final String nome;
    private final String email;

    public UsuarioDTO(String nome, String email) {
        this.nome = nome;
        this.email = email;
    }

    public String getNome() {
        return nome;
    }

    public String getEmail() {
        return email;
    }

    @Override
    public boolean equals(Object o) {
        // ... (várias linhas de implementação)
    }

    @Override
    public int hashCode() {
        // ... (várias linhas de implementação)
    }
}

Isso funciona? Sim. Mas são dezenas de linhas para algo puramente estrutural. É ruído visual.

Aplicando o KISS (Com Java moderno): Usando Records (introduzidos de forma definitiva no Java 16 e muito presentes no Java 17 e 21), resolvemos o mesmo problema de forma simples e direta, focando apenas no que importa: os dados.

public record UsuarioDTO(String nome, String email) {}

Uma única linha. Simples, imutável por padrão e fácil de ler.

Exemplo 2: Evitando Padrões Complexos Prematuramente

Imagine que precisamos retornar uma mensagem de status de acordo com o nível do usuário.

Sem KISS (Superengenharia): A vontade de aplicar "Clean Code" e padrões de projeto a qualquer custo pode nos levar a criar uma interface CalculadoraStatus, e três classes diferentes implementando essa interface (StatusIniciante, StatusIntermediario, StatusAvancado), mais uma Factory para instanciá-las. Tudo isso para um comportamento estático simples.

Aplicando o KISS (Usando Switch Expressions): Podemos usar as Switch Expressions modernas do Java para resolver a regra de negócio no mesmo lugar, de forma concisa e muito mais fácil de acompanhar.

public String obterMensagem(Nivel nivel) {
    return switch (nivel) {
        case INICIANTE -> "Continue estudando e praticando!";
        case INTERMEDIARIO -> "Você está no caminho certo, hora de aprofundar.";
        case AVANCADO -> "Excelente domínio técnico!";
    };
}

Não criamos 4 arquivos novos. Não espalhamos a lógica. Resolvemos o problema com a ferramenta mais simples e elegante disponível.

Quando a Arquitetura fere o KISS

Um ponto importante para nós, desenvolvedores, é ter cuidado ao aplicar padrões arquiteturais robustos, como Clean Architecture, Hexagonal ou Domain-Driven Design (DDD).

Esses padrões são fantásticos para domínios complexos. Porém, se você está desenvolvendo uma funcionalidade que é apenas um CRUD (Criar, Ler, Atualizar, Deletar) simples — como um formulário de contato —, rotear essa chamada por Controllers, UseCases, Ports Input/Output e Adapters é violar o princípio KISS.

Adapte a arquitetura ao tamanho do problema, não o contrário.

Conclusão

Ser sênior não é escrever o código mais complexo possível para mostrar conhecimento. É ter o repertório técnico para resolver problemas cabeludos da forma mais simples e manutenível possível.

A simplicidade é, de fato, o último grau de sofisticação.

E você? Já passou pela situação de aplicar uma boa prática no dia a dia e só depois descobrir que ela tinha um nome oficial? Deixe aqui nos comentários!