KISS - Mantenha Isso Estupidamente Simples

Receba em primeira mão, e com prioridade, os conteúdos Android exclusivos do Blog. Você receberá um email de confirmação. Somente depois de confirma-lo é que poderei lhe enviar os conteúdos exclusivos.

Email inválido.
Blog /Android /KISS - Mantenha Isso Estupidamente Simples

KISS - Mantenha Isso Estupidamente Simples

Vinícius Thiengo
(2510) (16)
Go-ahead
"A atividade que você está mais evitando contém sua maior oportunidade."
Robin S. Sharma
Kotlin Android
Capa do livro Desenvolvedor Kotlin Android - Bibliotecas para o dia a dia
TítuloDesenvolvedor Kotlin Android - Bibliotecas para o dia a dia
CategoriasAndroid, Kotlin
AutorVinícius Thiengo
Edição
Capítulos19
Páginas1035
Acessar Livro
Treinamento Oficial
Android: Prototipagem Profissional de Aplicativos
CursoAndroid: Prototipagem Profissional de Aplicativos
CategoriaAndroid
InstrutorVinícius Thiengo
NívelTodos os níveis
Vídeo aulas186
PlataformaUdemy
Acessar Curso
Receitas Android
Capa do livro Receitas Para Desenvolvedores Android
TítuloReceitas Para Desenvolvedores Android
CategoriaDesenvolvimento Android
AutorVinícius Thiengo
Edição
Ano2017
Capítulos20
Páginas936
Acessar Livro
Código Limpo
Capa do livro Refatorando Para Programas Limpos
TítuloRefatorando Para Programas Limpos
CategoriaEngenharia de Software
AutorVinícius Thiengo
Edição
Ano2017
Capítulos46
Páginas599
Acessar Livro
Quer aprender a programar para Android? Acesse abaixo o curso gratuito no Blog.
Conteúdo Exclusivo
Receba em primeira mão, e com prioridade, os conteúdos Android exclusivos do Blog.
Email inválido

Opa, blz?

Muito provavelmente você ao menos já deve ter ouvido falar nos livros “Código Limpo”, “O Codificador Limpo” e “Programador Pragmático”. Todos livros excelentes para developers de qualquer linguagem (mesmo que um ou outro tenha exemplos somente em Java)

Já ouviu falar em KISS (Keep It Stupid Simple ou Keep It Simple, Stupid)? 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 tem como principio manter a simplicidade e descartar a complexidade, no contexto de desenvolvimento de software o "descartar a complexidade" seria algo como quebrar aquele script complexo em “n” partes simples e de resolução única, ou seja, cada parte se limitaria a resolver somente uma única tarefa do problema principal.

Estudando padrões no Android acabei por cair na postagem de Filip Hanik. Li o post e estudei um pouco mais sobre o KISS, e final das contas, concordei com o conteúdo. Se não conhece Filip Hanik é engenheiro de software com mais de 15 anos de experiência e um dos membros da Apache Software Foundation, sendo expert no Apache Tomcat (melhor apresentação em: http://www.tomcatexpert.com/users/fhanik).

No post Filip fornece uma espécie de checklist ao qual nós developers deveríamos estar seguindo, nada referente a “utilize esse padrão”, “utilize essa linguagem”, “utilize esse IDE”, … são na verdade dicas simples e que surgem efeitos duradouros principalmente em termos de manutenção.

Segundo Filip nós developers temos o comum problema de complicarmos ainda mais os problemas de algoritmos enviados a nós, utilizando soluções complexas pensando serem elas as mais reutilizáveis.

O que seriam soluções complexas?

Classes com 500-1000 linhas de código, scripts com soluções complexas não diminuídos o suficiente para manter cada parte resolvendo uma única e mínima tarefa (vários métodos ao invés de alguns poucos e longos)… isso com muitas vezes simples problemas enviados a nós developers, digo, a utilização de soluções complexas para simples problemas.

O autor então descreve quais são os benefícios de utilizar os princípios do KISS em sua codificação, são eles:

  • Você será capaz de resolver mais problemas e com ainda mais eficiência;
  • Você será capaz de produzir scripts que resolvem problemas complexos com poucas linhas de código;
  • Seus códigos terão muitos mais qualidade;
  • Você será capaz de construir grandes sistemas fáceis de manter;
  • Sua base de código será mais flexível, fácil para estender, modificar ou refatorar quando novas funcionalidades forem solicitadas;
  • Você será capaz de produzir mais do que já imaginava como um developer;
  • Você será capaz de trabalhar em grandes grupos de desenvolvimento e em grandes projetos desde que todos mantenham os códigos estupidamente simples.

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

Abaixo são listados os passos para a aplicação dos princípios, porém tenha em mente que segundo o autor esse é um processo que mesmo sendo simples exige paciência, a maior parte dela com você mesmo, o developer. Seguem os passos:

  • Seja humilde, não pense que você é um super gênio, esse é seu 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 código;
  • Quebre as tarefas em sub-tarefas que você sabe que vão levar não mais que 4-12 horas de codificação;
  • Quebre os problemas em problemas ainda menores onde cada problema tem de ser passivo de ser resolvido em uma ou poucas classes (esse é bem similar ao passo anterior, porém o anterior é com ênfase no tempo);
  • Mantenha os métodos pequenos. Cada método não pode ter mais que 30-40 linhas de código. Cada método deve resolver apenas um pequeno problema. Se você tem várias condicionais em seu método, transforme essas em outros menores métodos. Esses rearranjos não somente deixaram seus códigos fáceis de ler e manter como também será bem mais tranquilo e rápido encontrar e corrigir bugs;
  • Mantenha pequenas as classes de seu domínio do problema;
  • Primeiro resolva o problema, então depois codifique. Muitos developers resolvem os problemas enquanto estão codificando, para os que têm essa habilidade não há nenhum problema quanto a isso, porém não tenha receio em refatorar seu código muitas e muitas vezes até encontrar o ponto em que ele é mais eficiente. Não se trata apenas de quantidade de linhas de código, mas se for percebida uma resolução ainda melhor e em apoio a essa resolução uma necessidade menor de linhas de código, então também refatore;
  • Não tenha receio em deletar parte do código. Refatorar e recodificar são duas importantes áreas no desenvolvimento de software. Se vierem 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 e se seguiu os passos acima será bem mais simples de apagar parte do código sem danos críticos a outras partes do sistema e reescrever uma solução melhor / nova para tais funcionalidades;
  • Para todos os cenários, sempre tente colocar o código o mais simples possível, esse é o comportamento mais complicado de se aplicar, mas depois de aplicado a primeira vez você verá que estava programando de maneira menos eficiente antes dos princípios do KISS.

Segundo o autor alguns dos melhores algoritmos são muitas vezes aqueles com poucas linhas de código. E quando nós vamos entre as linhas de códigos, podemos facilmente entender o que está sendo feito. A inovação consiste em quebrar o problema cada vez mais em problemas menores a ponto de eles ficarem muito fáceis de entender e implementar. Muitos dos grandes solucionadores de problemas de códigos não são excelentes codificadores, mas eles ainda produzem um excelente (simples) código.

Conclusão

O que tenho como experiencia, sem sombra de dúvidas, ter métodos menores resolvendo um único problema é sim uma excelente escolha de codificação, porém sei que quando surge a solução na cabeça o caminho comum é correr e codificar e quando terminamos temos aquele método longo que se pouco com algumas centenas de linhas de código. Não vejo problemas nisso, mas a ideia que não pode ser esquecida é a de voltar e refatorar, quebrando aquele único método em vários outros.

Pode ser que essa ideia de quebrar a solução em mais métodos não seja tão óbvia logo depois da resolução implementada, porém quando voltar para tentar entender / encontrar um bug ou até mesmo melhorar o código, ai sim o tempo gasto no entendimento do código é pesado, mesmo com os conhecidos comentários de assinatura de método, pois estamos falando de centenas de linhas de código.

Se já conhece o AndroidAnnotations library deve ter visto a frase de Robert C. Martin logo no rodapé da home: “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]."

Os principios do KISS são tranquilos de seguir, porém são apenas alguns bons principios do que realmente é o campo de boas práticas de programação, um mundo muito maior e com “n” livros, que se você tiver tempo (ou não) vale sim a leitura.

Uma dica que utilizo frequentemente para solucionar problemas que a principio não são simples nem mesmo colocando eles divididos em vários métodos. Utilizo muito fluxograma, com isso respeito o principio “Primeiro resolva o problema, então depois codifique” e dessa forma, no momento de codificar as condicionais / métodos, é bem mais tranquilo, pois o core, o problema, já foi resolvido no papel.

Outra dica é utilizar código autocomentado, onde os métodos e variáveis têm nomes completos (sem abreviações) do que eles fazem ou significam no sistema. Exemplo: getUsersNaoConfirmadosBoxEmail() é mais intuitivo que getUsersNaoConfirmadosBE().

Fonte artigo:

https://people.apache.org/~fhanik/kiss.html

https://en.wikipedia.org/wiki/KISS_principle

http://www.projectbuilder.com.br/blog-pb/entry/conhecimentos/keep-it-simple-stupid-porque-e-importante-manter-a-simplicidade-na-hora-de-definir-o-escopo-do-projeto

Vlw

Receba em primeira mão, e com prioridade, os conteúdos Android exclusivos do Blog.
Email inválido

Relacionado

Persistência de Dados Com Realm no Android - Parte 1Persistência de Dados Com Realm no Android - Parte 1Android
De Zero A UmDe Zero A UmLivros
Monetização Eficiente no Android com APPODEALMonetização Eficiente no Android com APPODEALAndroid
PHP - Programando com Orientação a ObjetosPHP - Programando com Orientação a ObjetosLivros

Compartilhar

Comentários Facebook (9)

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.
Enviando, aguarde...
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
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
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