Ao desenvolver, às vezes surge aquela sensação estranha de que escrever código complicado significa fazer um bom trabalho.
Adicionamos vários padrões de projeto, empilhamos camadas de abstração e criamos interfaces antecipadamente porque “talvez seja preciso expandir isso depois”.
Mas, quando você abre esse código novamente alguns anos depois, percebe que quem realmente sofre é o seu eu do futuro.
Hoje, vamos falar sobre KISS, o princípio que está no extremo oposto.
Indo direto ao ponto, KISS é a sigla de “Keep It Simple, Stupid”. Literalmente, algo como “Mantenha simples, seu idiota”.
É uma filosofia de design segundo a qual os sistemas funcionam melhor quando são mantidos simples, e não quando são construídos de forma complexa.
De onde veio o princípio KISS?
Essa expressão originalmente não era um termo de software.
A frase é atribuída a Kelly Johnson, engenheiro aeronáutico da Lockheed nos Estados Unidos durante a década de 1960. Ele projetou os famosos aviões de reconhecimento U-2 e SR-71 Blackbird.
Dizem que foi isso que Kelly Johnson exigiu da equipe.
Construam uma aeronave que um mecânico comum consiga consertar em combate usando apenas ferramentas básicas.
Por mais brilhante que seja o design, ele não serve para nada se não puder ser reparado em campo.
Essa mentalidade chegou ao software. Por mais engenhoso que seja o código, ele não é bom se os colegas não conseguem lê-lo e corrigi-lo.
A propósito, “Stupid” não chama os desenvolvedores de idiotas; a ideia é mais próxima de “simples o bastante para qualquer pessoa entender”.
Momentos em que o KISS se perde no código
É fácil dizer, mas como isso aparece no código real? Vou mostrar alguns padrões que encontro com frequência.
1. Uma linha que parece impressionante
// Assim você parece inteligente
let result = arr.reduce([Int: Item]()) { $0.merging([$1.id: $1]) { _, new in new } }
// Assim fica muito mais fácil de ler
var result = [Int: Item]()
for item in arr {
result[item.id] = item
}O código acima é curto, mas quem o vê pela primeira vez precisa examiná-lo por um bom tempo. O código abaixo qualquer pessoa entende em três segundos.
2. Extensibilidade que você nunca vai usar
Por exemplo, usar os padrões Factory e Strategy para criar um único botão. A preocupação é “E se os tipos de botão aumentarem depois?”. Mas esse “depois” quase nunca chega.
3. O labirinto de condicionais
Um if dentro de outro if, e mais um if dentro dele. Com apenas três níveis de aninhamento, a pilha mental já transborda. Nesses casos, simplesmente achatar o código com early return pode deixá-lo muito mais simples.
3 critérios práticos para seguir o KISS
Por isso, uso estes três critérios ao escrever código.
| Critério | Pergunta |
|---|---|
| Teste da explicação | Consigo explicar este código ao colega ao lado em um minuto? |
| Teste do futuro | Eu o entenderei imediatamente quando olhar para ele daqui a seis meses? |
| Teste da necessidade | Adicionei este código porque ele é necessário agora ou porque acho que talvez o use algum dia? |
Se alguma resposta for “não”, penso novamente se existe uma forma mais simples.
O terceiro é especialmente importante, pois se relaciona ao princípio YAGNI (You Aren’t Gonna Need It). KISS e YAGNI praticamente andam juntos.
Simples não é o mesmo que malfeito
Há uma coisa que não podemos entender errado aqui.
KISS não significa “escreva sem pensar”. Na verdade, significa exatamente o contrário.
Complicar é fácil: basta acrescentar tudo o que vier à cabeça. Simplificar é difícil, porque é preciso pensar cuidadosamente no que remover.
Pascal deixou uma frase famosa em uma carta.
Não tive tempo de escrever de forma mais curta, então escrevi de forma mais longa.
Com código é igual. Código simples não é resultado de desleixo, mas do esforço para remover a complexidade.
Resumo
Em resumo, o princípio KISS é o seguinte.
- O código passa muito mais tempo sendo lido do que sendo escrito. Escreva de forma simples para quem vai lê-lo.
- Não adicione extensibilidade que não é necessária agora. A situação com que você se preocupa acontece com menos frequência do que imagina.
- Simplicidade não é falta de habilidade; é prova de habilidade.
Ultimamente, o comentário que mais deixo em code reviews é: “Não dá para deixar isso mais simples?”. Curiosamente, essa única pergunta reduz tanto os bugs quanto o tempo de revisão.
Seu colega ao lado consegue entender seu código em um minuto? Espero que você se faça essa pergunta hoje.