KISS - Mantenha Isso Estupidamente Simples

Tudo bem?

Muito provavelmente você ao menos já deve ter ouvido falar dos livros Código Limpo, O Codificador Limpo e “Programador Pragmático”. Certo?

Todos esses são livros excelentes para desenvolvedores de qualquer linguagem, mesmo sabendo que os exemplos em maioria são em Java.

Agora uma pergunta:

Você já ouviu falar em KISS (Keep It Stupid Simple ou Keep It Simple, Stupid) na Engenharia de Software?

Em tradução livre seria algo como "Mantenha Isso Estupidamente Simples" ou "Mantenha Isso Simples, Estupido".

O termo foi cunhado na década de 60 quando um engenheiro da marinha americana, Kelly Johnson, explicou aos seus subordinados que os aviões deveriam ser simples a ponto de que se algum problema ocorresse em campo de batalha, qualquer mecânico mediano fosse capaz de concerta-lo.

O termo KISS tem como objetivo:

Manter a simplicidade e descartar a complexidade.

No contexto do desenvolvimento de software o "descartar a complexidade" seria algo como:

Quebrar aquele algoritmo complexo em “n” partes simples onde cada parte teria uma única responsabilidade.

Exatamente o que o eXtreme Programming (uma metodologia ágil) já trata também como princípio.

Indo mais a fundo na Engenharia de Software, em contexto mobile. Mais precisamente estudando a aplicação de padrões no desenvolvimento Android.

Neste roteiro de estudo eu acabei esbarrando na postagem de Filip Hanik.

E sim, eu li todo o artigo de Hanik e resolvi então estudar ainda mais sobre o KISS.

Research aqui, research li... final das contas: concordei com todo o conteúdo do artigo de Hanik.

Primeiro, antes de prosseguir, eu acredito ser prudente informar quem é Filip Hanik...

Hanik é Engenheiro de Software com mais de 18 anos de experiência na área de desenvolvimento. Ele é também um dos membros da Apache Software Foundation. Sendo expert no Apache Tomcat.

Voltando ao tópico "o artigo KISS de Hanik"...

esse artigo fornece uma espécie de checklist ao qual nós desenvolvedores deveríamos estar seguindo no dia a dia profissional.

Calma! Não é nada referente a "utilize esse padrão", "utilize essa linguagem”, "utilize esse IDE”.

São na verdade dicas simples que quando aplicadas geram efeitos duradouros principalmente em termos de manutenção de projeto de software.

Segundo Hanik, nós desenvolvedores temos o péssimo hábito de complicarmos ainda mais os problemas de algoritmos enviados a nós. Normalmente utilizando soluções complexas pensando serem elas as mais sensatas.

Ok, Thiengo. Mas o que você quer dizer com "soluções complexas"?

Vou ser sincero, há inúmeros exemplos. Mas vamos a dois clássicos:

1º - Classes com 1000-2000 linhas de código provavelmente têm mais de uma responsabilidade do domínio de problema dentro delas.

Isso é algo que fere ao menos as boas práticas de desenvolvimento orientado a objetos. Consequentemente, a facilidade de leitura do código é severamente atingida.

Pode chegar um momento que nem mesmo o criador da classe vai conseguir trabalhar nela.

2º - Comunicação direta entre camadas que não deveriam se comunicar diretamente. Isso utilizando APIs nada simples que exigem configurações globais no projeto.

Esse aliás é um problema sério o suficiente a ponto do Google Android depreciar a API LocalBroadcastManager que basicamente permite isso: a comunicação entre quaisquer camadas.

Isso, no médio e longo prazo, simplesmente destrói a possibilidade de evolução saudável do projeto de software.

Sem contar que quando as camadas do aplicativo são mal trabalhadas, os testes automatizados também ficam dificultados.

Voltando ao artigo de Hanik...

o autor não deixa de descrever quais são os benefícios de utilizar os princípios do KISS na codificação. São eles:

• Você será capaz de resolver mais problemas com ainda mais eficiência;

• Você será capaz de produzir algoritmos, com poucas linhas de código, que resolvem problemas complexos;

• Seus códigos terão mais qualidade, principalmente em termos de leitura;

• Você será capaz de construir grandes sistemas (ao menos ser parte do time de desenvolvedores) fáceis de manter;

• Sua base de código será mais flexível. Fácil de estender, modificar ou refatorar;

• Você será capaz de produzir mais do que já imaginava como um desenvolvedor de software;

• Você será capaz de trabalhar em grandes grupos de desenvolvimento e em grandes projetos desde que todos mantenham os códigos estupidamente simples.

Ok, Thiengo. Mas como implementar os princípios do KISS em minha codificação diária?

Está certo...

a seguir são listados os passos para a aplicação dos princípios do KISS.

Porém tenha em mente que segundo Hanik:

A aplicação desses princípios é um processo que mesmo sendo simples exige paciência. Onde a maior parte dessa paciência será com você mesmo.

Seguem os passos:

1º passo

Seja humilde. Não pense que você é um super gênio. Aliás, esse costuma ser o primeiro erro.

Seu código pode ser muito simples e você não precisa ser gênio para trabalhar dessa forma.

A humildade vai permitir que você continue melhorando, refatorando, o código.

2º passo

Quebre as tarefas em subtarefas. O famoso: dividir para conquistar.

Isso sempre funciona como um dos melhores caminhos para resolver os problemas de codificação.

3º passo

Quebre os problemas em problemas ainda menores onde cada problema tem que ser passível de ser resolvido em uma ou poucas classes.

Esse passo é bem similar ao passo anterior, porém o anterior é com ênfase no tempo e esse é com ênfase no código fonte.

4º passo

Mantenha os métodos pequenos.

Cada método não pode ter mais do que 30-40 linhas de código. Cada método deve resolver apenas um pequeno problema.

Se você tem vários blocos condicionais em seu método, transforme esses blocos em outros métodos menores.

Esses rearranjos não somente deixarão seus códigos fáceis de ler e manter como também será bem mais tranquilo e rápido encontrar e corrigir bugs.

5º passo

Mantenha pequenas as classes de seu domínio do problema.

Se sua classe tem dezenas, quiçá centenas de métodos. Então provavelmente ela contém mais de uma responsabilidade do domínio do problema.

6º passo

Primeiro resolva o problema. No papel, por exemplo. Logo depois codifique.

Muitos desenvolvedores resolvem os problemas enquanto estão codificando. E normalmente esse não é o melhor caminho para resolver problemas com algoritmos.

Isso pois além de pensar na solução você também terá que pensar sobre os recursos da linguagem. Se ela fornece, por exemplo, uma API que facilita a escrita de uma possível solução.

A busca por essa API pode ser feita depois, quando a solução parcial já está definida em algum lugar que não seja em bits.

7º passo

Não tenha receio em deletar parte do código fonte.

Refatorar e recodificar são duas importantes tarefas no desenvolvimento de software.

Se chegarem a você pedidos de funcionalidades que ainda não existem ou que você não foi avisado sobre a possível implementação na época em que estava codificando o projeto...

e se você seguiu todos os passos anteriores...

então será bem mais simples de apagar parte do código fonte sem danos críticos a outras partes do aplicativo. E assim reescrever uma solução melhor (ou nova) para as funcionalidades.

Sem levar em consideração que no pior cenário você terá o controle de versão trabalhando a seu favor.

8º passo

Para todos os cenários: sempre tente colocar o código o mais simples possível.

Esse é o passo mais complicado de se aplicar. Mas depois de aplicado você possivelmente perceberá que estava programando de maneira menos eficiente antes dos princípios do KISS.

Segundo Hanik muitos dos melhores algoritmos que ele já conheceu são aqueles com poucas linhas de código.

Nesses algoritmos, quando nós "navegamos" entre as linhas de códigos, podemos facilmente entender o que está sendo feito.

Ou seja, a inovação na resolução de problemas consiste em quebrá-los cada vez mais em problemas menores, a ponto deles ficarem muito fáceis de entender e implementar.

Ainda segundo Hanik, muitos dos grandes solucionadores de problemas utilizando códigos fonte não são excelentes codificadores, mas eles ainda produzem um excelente e simples código.

Conclusão (será?)

Se você já é veterano de guerra, muitos anos como profissional de desenvolvimento. Então é provável que este artigo não tenha lhe falado muito do que você já não sabia.

Porém mesmo assim é válido ressaltar que até mesmo nós, mais veteranos, às vezes, na correria de entregar tickets, passamos por cima de coisas simples.

Coisas que muitas vezes não exigem nem mesmo um pensamento lógico de nossa parte, é apenas trabalho mecânico. Trabalho como:

• Reduzir a responsabilidade de métodos quebrando eles em métodos ainda menores;
• Trabalhar a ideia de código auto comentado, onde as propriedades e métodos têm nomes explicativos ao que eles armazenam e processam;
• Utilizar variáveis de explicação para blocos condicionais complexos;
• ...

Verdade seja dita... não só para iniciantes no desenvolvimento de software, mas para todo o cenário de TI:

Se manter ciente, estudar, as boas práticas e como entregar o melhor código possível em um tempo aceitável. Isso nunca se torna algo antigo ou "já estudado o suficiente".

É simplesmente uma questão de bom senso. Consumir cada vez mais e praticar. Os resultados sempre vêm.

Antes de finalizar, acredito ser prudente parafrasear um dos popstars do desenvolvimento ágil de software. O "nada" popular Robert C. Martin:

“A proporção de tempo gasto lendo código versus a escrita dele é bem mais do que 10 para 1… portanto tornando-o fácil de ler faz com que seja mais fácil de escrever [refatorar]."

Bom, é isso.

Espero que o artigo tenha ao menos lhe intrigado em querer saber mais sobre "codificação limpa". Se sim, então certamente eu e Filip Hanik atingimos o nosso objetivo.

Se você já tem certa experiência como desenvolvedor e sabe também de outras metodologias ou técnicas úteis de desenvolvimento de aplicativos.

Então sinta-se em casa para divulgar logo abaixo nos comentários.

E não se esqueça de se inscrever na lista de e-mails do Blog 📩  (que é gratuita) e assim passar a receber também os conteúdos exclusivos que eu disponibilizo somente por lá.

Abraço.

Fontes

• The Kiss Principle;
• KISS principle;
• Keep It Simple, Stupid: Porquê é importante manter a simplicidade na hora de definir o escopo do projeto.

Relacionado

Persistência de Dados Com Realm no Android - Parte 1Android

De Zero A UmLivros

Monetização Eficiente no Android com APPODEALAndroid

PHP - Programando com Orientação a ObjetosLivros

Comentários Blog (7)

Para código / script, coloque entre [code] e [/code] para receber marcação especifica.

Forneça seu nome válido.

Forneça seu email válido.

Forneça o comentário.

Enviar

Enviando, aguarde...

mbcampolino (4) (0)

09/01/2016

olá Thiengo beleza? meu nome é marcos e tenho uma ideia de acessibilidade para o app...talvez nos artigos você poderia deixar uma opção para escutar. mas com sua voz mesmo(sem Google) aí upava o áudio em algum lugar e usava a classe média player nessa tela ativada por algum botao para ouvir suas reviews. abraços

Responder

Vinícius Thiengo (2) (0)

09/01/2016

Campolino, show de bola a ideia. Vou sim estudar a possibilidade. Abraço

Responder

mbcampolino (1) (0)

04/02/2016

Vlw Thiengo. Aguardamos por novidades então lol...talvez você poderia aproveitar para ensinar no canal sobre o assunto...text to speech e speech to text a fundo. eu andei vendo uns tutoriais ótimos sobre. abraços

Responder

mbcampolino (1) (0)

04/02/2016

então tanto faz, usando média player ou tts seria ótimo. abraços ( melhor com média player rsrsrs )

Responder

icaropinhoe (1) (0)

04/01/2016

Fala thiengo, pretende fazer review de alguns livros da casa do código? eles são mais baratos e acessíveis.

Responder

Vinícius Thiengo (0) (0)

05/01/2016

Fala Icaro, blz?
Possivelmente, teria de ver se há algum título que queira estudar. Vou ver os títulos deles. Abraço

Responder

plinhares9 (2) (0)

02/01/2016

Legal, gostei ! Sem dúvida alguma a grande vantagem disso é a diminuição do tempo de leitura de código quando faz algum tempo que você não mexe naquele ponto. Pois neste caso, mesmo o código sendo apenas seu, por incrível que pareça , a leitura ainda se torna de difícil entendimento se não estiver escrito de forma simples e seguindo padrões. Valeu Thiengo.

Responder