Regra 1: O mais simples possível, mas não mais simples do que isso

Série de artigos sobre o livro As Regras da programação de Chris Zimmerman. O livro trata de 21 regras que ajudam programadores a criarem códigos melhores. Falarei um pouco sobre cada regra do meu ponto de vista trazendo alguns exemplos e opiniões sobre o livro, com o objetivo principal de consolidar e compartilhar o conhecimento.

Uma das habilidades mais necessárias como programador é a capacidade de abstrair o problema e encontrar possíveis soluções. Eu acredito que esse é o ponto chave dessa regra: pensar no problema.

O autor diz “(…) a melhor maneira de implementar uma solução para qualquer problema é a mais simples que atenda a todos os requisitos desse problema.”. Fica obvio por essa frase que abstrair o problema é essencial. Compreender todos os desdobramentos, requisitos e até avaliar a sua complexidade.

Essa investigação sobre o problema pode nos mostrar que não existe uma solução simples para uma definição ampla do mesmo, mas se o quebrarmos em pequenos pedaços podemos encontrar soluções simples e que resolvam a parte do problema que realmente precisa ser resolvida. Sobre isso o autor diz “Se não conseguir simplificar a solução, tente simplificar o problema”.

É melhor que o código seja mais simples (desde que resolva o problema), mas como avaliar essa simplicidade? Existe um limite pra isso? O livro expõe 3 critérios básicos para a avaliação da simplicidade: quantidade de código escrita, quantas ideias foram introduzidas e quanto tempo seria necessário para explicá-lo (facilidade de criação e facilidade de compreensão).

Particularmente acho que o primeiro critério não deve ser uma “regra”, nem sempre o código que possui menos linhas é o mais simples. Muitas vezes ele causa uma dificuldade de compreensão do que está sendo feito naquele trecho devido a suas implementação extremamente resumida. Uma boa abstração desses critérios é “Um código simples é fácil de ler – e um código mais simples pode ser percorrido totalmente do início ao fim, como lemos um livro.” como o próprio autor diz.

Pra finalizar, quanto mais complexo fica o código mais difícil fica trabalhar com ele e progredir se torna cada vez mais lento. Sempre que puder procure oportunidades para remover complexidade ou projete soluções de forma que novos recursos não aumentem a complexidade do inicial. Faça sua equipe trabalhar em conjunto da forma mais simples possível.