Clean Code

Alguma vez algum bloco de código já te atrasou consideravelmente? Se sim, possivelmente esse tal bloco consistia em código mal formulado, um código ruim, um código sujo.

Código Sujo

Um código ruim ou sujo te limita ter a visibilidade e a previsão de entrega, parece que você está em uma areia movediça, que, quanto mais você se mexe, mais se afunda e fica preso no código.

Podemos fazer uma outra analogia também, à um mapa, que esteja todo sujo e rabiscado, ao tentar utilizá-lo, ficaríamos perdidos e não saberíamos por onde seguir para achar o nosso objetivo.

Um código ruim pode, ao longo prazo, arruinar um projeto, até mesmo falir uma empresa.

Escrever um código legível é tão importante quanto escrever um código que funciona.

Mas porque escrevemos códigos sujos?

Nós não escrevemos códigos ruins de propósito, existem fatores que influenciam nessa má prática, algumas delas são:

• Prazos apertados: você precisava entregar , não importa como, só fez funcionar.
• Códigos já estavam sujo ah! já tava assim, vamos só acrescentar mais algumas linhas nessa sujeira toda.
• Cansado da mesma tarefa: você já não estava mais suportando aquela tarefa ou projeto, e entregou de qualquer forma.
• Só eu mexo nesse código: você acredita que ninguém mais irá “pôr a mão” no teu código futuramente, e por isso faz o famoso “eu conheço minha bagunça, sei onde estão as coisas”.

O que é CleanCode?

Clean code, como o nome já diz, se trata de um “código limpo”, um código eficiente com propostas claras, suas atribuições bem definidas, facilitando assim a manutenção, leitura e futuras implementações.

Tempo gasto no momento de desenvolvimento

Um código limpo, é aquele código que você percebe que o desenvolvedor se importou ao escrevê-lo, que a lógica que você está lendo já te entrega o resultado final.

Existem vários princípios para mantermos um código limpo. Posso listar vários aqui, mas, se não for praticado, nunca será aprendido em sua jornada como desenvolvedor.

Por isso, para que um bom código seja desenvolvido de modo que, seja algo natural, algo intrínseco em seu algoritmo ao escrevê-lo, é necessário um trabalho árduo e requer mais do que o conhecimento e padrões.

Princípios

Nos anos 50, uma abordagem surgiu chamada Manutenção Produtiva Total (Total Productive Maintenance), se tratando de um sistema que visava mensurar o tempo gasto em manutenção, e assim, seguindo os princípios 5S, poder reduzir este tempo gasto em manutenção.

No livro Clean Code, de Robert Martin, diz que:

… a maior parte do trabalho não está na fabricação, mas na manutenção — ou na prevenção. Em software, 80% ou mais do que fazemos é chamado de "manutenção": ato de reparar.

Os princípios são (já convertido para a área de desenvolvimento):

• Ordenar — Nomeie suas funções, variáveis, arquivos, etc. adequadamente!
• Sistematizar — Cada coisa em seu lugar!
• Limpeza — Evite blocos de comentários desnecessários!
• Padronização — A equipe inteira deve manter e seguir padrões!
• Disciplina — Siga as regras e esteja disposto às mudanças!

Vamos aprofundar um pouco em cada desses princípios?

Ordenar: Use nomes que revelam seu propósito!

Nomes de variáveis

Escolher nomes de variáveis, algumas vezes, é difícil.

Algo muito ruim, é quando, ao ler um código, você se esbarra em um nome que não demonstra o seu propósito, não revela nada:

var d; //tempo decorrido em dias

Se o nome requer um comentário explicativo, provavelmente este é um nome ruim.

Imagine um cenário onde esta variável esteja sendo usada em outro escopo do código, você colocará este comentário ao lado também?

Que tal colocar essa informação no portador da informação, na própria variável? Segue alguns exemplos:

var tempoDias;
var duracaoDias;
var diasDuracao;

Agora, independente do escopo onde estiver esta variável, será uma variável que demonstrará o que ela deverá armazenar, o seu propósito, a duração em dias.

Agora, veja o algoritmo a seguir:

Quanto tempo você levou para interpretar esse código? mesmo conseguindo entender a lógica do que ele faz, ainda sim fica muito abstrato exatamente o que significa cada variável.

Agora veja o mesmo código com os nomes das variáveis mais explícitos:

Perceba-se que, nada mudou além dos nomes das variáveis, temos as mesmas quantidades de linhas e de variáveis e de complexidade, porém a leitura ficou muito mais agradável e fácil de se entender, e com muito mais informações sobre as variáveis, algo que era impossível anteriormente, por exemplo, descobrimos a unidade que ele armazena, em segundos.

Nomes de classes e funções/métodos

Vimos um pouco sobre os nomes das variáveis, mas e nomes de classes e funções/métodos?

Deve-se seguir praticamente a mesma regra, dar propósito a elas, contudo, com alguns pontos a resalvas:

• Classes: Devem ter nomes com substantivo(s), já que será uma representação de uma entidade. Ex: Pessoa, Cliente, Endereco, Carro.
• Métodos/Funções: Devem ter verbos, pois devem representar ação que aquele pedaço de código realizará. Ex:, obterSobrenome, guardarCPF, salvarEndereco, guardarPlaca.

Esses são apenas algumas das práticas relacionadas a nomeação, existe outras que são tão importantes quanto, seguimos para o próximo princípio.

Sistematizar: Cada coisa em seu lugar!

As funções são a primeira linha de organização, escrevê-la bem é fundamental.

Vamos supor que você tenha um dicionário em suas mãos, e eu te pedisse para procurar sobre a palavra “Resultados”, você com certeza abriria o dicionário diretamente na parte onde começa palavras com a letra “R”, correto? E não começar na letra “A”, que faria você perder um bom tempo procurando.

Agora veja a imagem que ilustra um artigo sobre um assunto qualquer, do lado esquerdo não temos uma separação por tópicos ou assunto, já a direta sim:

Perceba-se que, quando separamos os textos por tópicos, fica muito mais claro do que aquela pequena parte de texto aborda e muito mais rápido achamos o que procuramos.

Mas como isso se aplica nos nossos códigos? Simples! Quanto menor a função, melhor!

Quanto menor a função é, menor é a chance de erros, já que ao criá-la você estará tão envolvido naquele pequeno escopo de código e conseguirá enxergar algum erro que poderia passar despercebido se fosse uma função maior.

Uma função maior tende a ser mais complexa, ter mais combinações, mais lógicas, mais chances de bugs e consequentemente mais difícil de encontrar e isolar ela.

Quando você tem uma função pequena, a probabilidade da lógica ser mais clara e delimitada é maior, por isso, durante a busca de um erro, por exemplo, fica mais fácil acharmos e descartarmos funções mais rapidamente, até acharmos a(s) função(ões) problemáticas, assim, com muito mais facilidade, corrigirmos o erro com mais eficiência.

Veja o exemplo abaixo e me diga se não fica bem mais fácil de encontrar o ponto exato do caso o erro seja de “Caracteres Especiais”

Pode parecer estranho uma função de uma linha, mas imagina se essa linha tivesse no meio de escopo maior, seria muito mais difícil isolar e analisar o erro.

E um detalhe, quando uma função é pequena, ela provavelmente, terá apenas uma atribuição, e ela será especialista naquele assunto.

Outro ponto a ressaltar é a escalabilidade delas, caso algum momento seja necessário utilizar a mesma lógica de limpeza de caracteres especiais, poderemos reutilizar a mesma função.

Mas calma lá, não vai saindo agora criando funções de apenas uma linha!

Tudo depende do nível de abstração que você irá utilizar, se para você não será válido chamar 4 funções invés de apenas uma, o ideal aqui é chamá-las dentro de uma maior:

Tudo excessivamente não é bom, o ideal é encontrar um meio termo, um nível de abstração que encaixe em seu projeto.

Acredito que deva estar um pouco mais claro em relação a este princípio, 'bora' para o próximo!

Limpeza: Evite comentários desnecessários!

Os comentários são um mal necessário, pois se nossas linguagens de programação fossem expressivas o suficiente não necessitaríamos de quase nenhum comentário.

Comentários não devem expressar uma ideia. É muito comum os desenvolvedores colocarem comentários acima de uma função ou de um explicando o que aquela parte do código faz, isso significa que o desenvolvedor foi incapaz de se expressar em código.

Claro que não podemos generalizar, pois dependendo da linguagem de programação, principalmente de baixo nível, se faz necessário.

Independente da linguagem, devemos ter em mente uma coisa, se escrevemos algum comentário de teor descritivo que o código faz, então não conseguimos nos comunicar com outros desenvolvedores através somente do código.

Se tivermos isso como base no desenvolvimento, nos forçará a criar um código mais legível com mais clareza.

Além disso, caso se depare com algum comentário descritivo, desconfie a princípio, pois ele pode não corresponder com a verdade. Por inúmeros motivos, esse comentário pode estar errado, ou atrasado por causa de refatorações constantes no código, veja o exemplo a seguir:

o comentário não acompanha as manutenções posteriores

Reparem na confusão do comentário e o resultado que será gerado, algum momento na implementação foi decidido que um padrão no formato da data, porém, com o tempo, surgiram fatores com que esse padrão de data precisasse ser alterado, fazendo que o comentário fosse "mentiroso". Isso pode gerar transtorno futuramente, se algum desenvolver, lesse pela primeira vez este código, esse comentário geraria uma falsa expectativa, tendo um diferente resultado final.

Existe 4 momentos oportunos que devem ser feitos comentários:

1. Gerar documentação: comentários que geram documentação, que demonstram as entradas, saídas, descrição, especificações de um determinado atributo ou função.
2. Para alertar algum desenvolvedor em alguma área sensível ou aparentemente inofensiva.
3. Explicar as regras de negócio ou a premissa envolvida naquele escopo de código.
4. Explicar do porque que foi utilizado aquela biblioteca e não a outra naquele momento, demonstrar as limitações que fez com que escolhesse tal biblioteca

Para não alongar demais vamos abordar os outros dois últimos princípios em outro momento posterior.

Livro Clean Code

Todo o conhecimento e informação passado neste post foi baseado no livro Clean Code.

Clean Code está sendo um livro com uma experiência única, mudando meus conceitos e vícios na hora de programar, Robert Martin, autor do livro, é também conhecido por ser um dos coautores do manifesto ágil (Agile software development).

Espero que este artigo tenha feito você mudar a forma como escreve seus algoritmos, como mudou a minha, pois tenho a certeza que, futuros desenvolvedores irão agradecer ao ler teu código.

Não basta escrever bons códigos, é fundamental mantê-los limpos.

Caso a bagunça já está feita, o caminho sugerido é a Refatoração!