6 técnicas do Clean Code que ajudam a reduzir custos com desenvolvimento e manutenção de sistemas na prática

Desenvolver sistemas com grande longevidade e fácil manutenção é um desafio comum enfrentado pela maioria dos times de engenharia de software. Isso requer mais que conhecimento técnico em padrões ou tecnologias do momento. Envolve a capacidade de tomar decisões durante o processo que impactará na experiência do próprio desenvolvedor que irá dar a manutenção no sistema.

Enquanto maior parte dos esforços são direcionados para a parte inicial do desenvolvimento de um novo sistema, a atenção com aspectos que facilitarão a manutenção no futuro continuará sendo negligenciada.

Passamos a maior parte do tempo estudando e lendo código escrito por outros desenvolvedores e muitas vezes, nos deparamos com trechos difíceis de entender, fazendo com que a maior parte do tempo investido seja apenas para a compreensão do que com a evolução de implementações.

Neste artigo, você conhecerá algumas técnicas de Clean Code que ajudam a reduzir os custos de desenvolvimento e manutenção e que também equilibram o tempo de compreensão com o tempo de evolução de novas implementações no código.

O que é Clean Code e por que aplicar suas técnicas?

O próprio nome já diz, mas de acordo com o livro, Clean Code, escrito por Robert C. Martin, “é um conjunto de atributos de qualidade aliado a boas práticas que garantem que um código possibilite fácil manutenção em todos os aspectos” . Resumindo, é um código simples, eficiente, testável, fácil de entender, de se manter, evoluir e reaproveitar independente de quem escreveu — seja júnior, pleno, sênior, desenvolvedor, analista, engenheiro ou arquiteto.

Mas por que aplicar as técnicas de Clean Code durante o desenvolvimento e manutenção?

• Ter um código limpo;
• Ajudar a reduzir a dívida técnica;
• Ter um time mais produtivo, incluindo novos membros;
• Vantagem competitiva na velocidade de desenvolvimento em relação ao concorrente;
• Obter ainda mais valor no futuro;
• Prevenir o software de se tornar legado pelo caos na manutenção.

Os motivos listados acima poupam incontáveis horas gastas com recursos que poderiam estar focados em construir uma nova solução, implementando melhorias que gerem valor para o negócio e para o próprio time de desenvolvimento, de forma rápida ou pensando nas próximas funcionalidades.

Também evitará que o produto tenha dívidas técnicas impagáveis, ou seja, impedindo que no futuro, mais horas de trabalho sejam gastas em itens técnicos que já deveriam ter o mínimo de qualidade garantida. Em outras palavras, retrabalho.

À medida que essa confusão aumenta, a produtividade diminui a quase zero. E é isso que as técnicas do Clean Code nos ajudam a evitar. Nos fazendo refletir sobre o impacto financeiro gerado e sobre a relação entre produtividade, qualidade e manutenção.

6 Técnicas de Clean Code

1 — Regra do escoteiro

Não basta escrever um código bom, é preciso melhorá-lo cada vez que o revisitarmos, pois qualquer código limpo pode ficar sujo com o tempo, por isso é importante ter a constante prática de melhoria contínua.

Isso não se limita ao mesmo trecho do código que foi desenvolvido ou alterado, e sim a qualquer parte dele. Não precisa ser algo grande, pode ser a troca do nome de uma variável, constante, método, função, classe ou eliminar uma pequena duplicidade de código.

Por que utilizar?

Quando isso se torna um hábito não há espaço para bagunça, para fazer as coisas de qualquer jeito independente do prazo ou pressão que ocorra. É uma questão de mentalidade e cuidado com a qualidade do trabalho realizado.

Essa prática evita que horas extras sejam dedicadas no futuro só para entender o que é e como foi feito.

2 — Use nomes a partir do domínio da solução

Tudo que for escrito no código será lido por outros desenvolvedores e todos os envolvidos no projeto precisam estar na mesma página.

Na prática, se algum analista de negócio ou responsável por um departamento da empresa fala de um termo específico em suas orientações de como quer que o sistema funcione, os mesmos devem ser utilizados quando o código for escrito e isso deve ser feito sem adaptações.

Por que utilizar?

Isso facilitará para outros desenvolvedores o que significa aquele termo. Por exemplo, pense em um sistema que está sendo desenvolvido para um banco, e o termo “francesinha” é mencionado pelas pessoas envolvidas no projeto, sendo que o termo represente o extrato de movimentação de títulos mantidos na carteira de cobrança bancária. A maioria das pessoas envolvidas com o contexto bancário está habituada com este termo.

Agora imagine o cenário em que o desenvolvedor acha o termo cômico ou não gosta dele e resolve escrever outro termo para substituir, como “XPTO” e implementa isso nas telas do sistema e no código.

Provavelmente os usuários que utilizam o app e estão acostumados com o termo ficarão sem entender o que significa “XPTO”, pois terão a sensação de que a funcionalidade “francesinha” deixou de existir. E não só os usuários, mas também nas reuniões que envolvem entendimento das regras de negócio que utilizam o termo para desenvolvimento de outras funcionalidades. E novos desenvolvedores que atuarem no projeto, pois serão aculturados com o termo errado que não é conhecido pelos envolvidos.

Usar nomes a partir do domínio da solução, ajuda o time a não perder tempo inventando termos não utilizados pela área de negócio e evita que desenvolvedores percam tempo tentando tirar dúvidas sobre o que significa enquanto poderiam estar focados em evoluir o que já existe com base no entendimento comum sobre os termos específicos da área de negócio.

3 — Use nomes passíveis de busca

“Usar nomes passíveis de busca” é uma técnica que está diretamente conectada a técnica de “Usar nomes a partir do domínio da solução”.

Durante o desenvolvimento do código-fonte é comum desenvolvedores buscarem atalhos para driblar a necessidade de pensar e dar nomes. Aliás, boa parte do desenvolvimento de sistemas consiste em “dar nome aos bois códigos”.

E usar nomes passíveis de busca é uma técnica que orienta a determinar que os nomes utilizados no código de um software sejam em variáveis, funções, classes, métodos, arquivos (trechos de código que são modificados com frequência), que sejam nomes fáceis de pesquisar. De forma que tenham uma identificação própria ou represente alguma informação de forma lógica. Diferente de usar apenas letras, códigos ou abreviações que só quem desenvolveu determinado trecho de código consegue entender.

Por que utilizar?

Essa técnica facilita a busca durante a manutenção. Os desenvolvedores que precisam realizar uma alteração facilmente saberão identificar o que faz determinados trechos de código pelo nome que foi dado e pelo que representa no contexto. Reduzindo a quantidade de tempo necessária para entender o que cada trecho faz ou o que significa.

Um exemplo comum, que pode representar de forma prática quanto tempo se perde não usando nomes passíveis de busca é o código que tem uma série de variáveis, funções, classes, métodos e arquivos com abreviações de termos verbosos (grandes) e letras como “i”, “a”, “j” que são utilizadas.

Agora, imagine quanto tempo o desenvolvedor que dará manutenção em um código cheio de letras e siglas que não representam nenhum conceito de negócio levará para realizar a entrega esperada pela área de negócio simplesmente porque “não deu nome aos bois códigos”? Gastos com horas e horas podem ser poupadas com essa técnica.

4 — Evite o mapeamento mental

Outra técnica que orienta o cuidado com os nomes dados nos códigos. Todo nome deve ser significativo e claro, seja de variável, funções, classes, arquivos, ou etc. Isso significa que devem ser óbvios.

O mapeamento mental faz com que desenvolvedores que tem contato com o código tentem adivinhar o que significa cada trecho. Inclusive o significado de siglas, letras, números perdidos e nomes que só fazem sentido na cabeça de quem escreveu o código.

Por que utilizar?

Pelo mesmo motivo que usar nomes a partir do domínio da solução e usar nomes passíveis de busca facilitam a procura e a compreensão por parte de quem está dando manutenção.

Isso reduz a quantidade de horas gastas com tentativas de entendimento do código que sofrerá alterações a curto, médio e longo prazo. Essa quantidade de horas não gasta, é uma grande economia, podendo em alguns casos economizar uma ou mais sprints.

5 — Evite repetição

Essa técnica está diretamente ligada a um princípio da própria programação, o DRY (Don’t Repeat Yourself). Como o próprio nome da técnica e o princípio afirmam: Evite repetição.

Ou seja, evitar a repetição de trechos de código e permitir que sejam reutilizados por meio de estruturas que possam ser usadas com pouco esforço, seja por meio de uma função, método, classe, arquivo etc.

Por que utilizar?

A repetição de código gera um efeito colateral que aumenta exponencialmente o consumo de horas em uma manutenção. Como? Ao alterar uma funcionalidade ou módulo que possui diversos códigos repetidos e espalhados fazendo a mesma coisa, vai exigir que quando uma regra ou trecho for alterado, os outros também sejam em diversos outros lugares. Em sistemas de médio e grande porte isso é um verdadeiro caos, pois quanto mais pontos duplicados houver, mais consumo de hora será necessário para alterá-los.

Com isso serão perdidas horas com:

• Pesquisa dos trechos duplicados;
• Alteração da mesma regra em vários pontos do sistema;
• Pesquisa dos trechos que não foram atualizados por esquecimento;
• Investigação da causa de um problema gerado por um trecho de código que foi copiado e duplicado sem avaliar seus detalhes.

Evitar repetição de código ajuda a reduzir o tempo de desenvolvimento e manutenção através do reaproveitamento, que é garantido conforme o código é modularizado, reduzindo o tempo de horas gastas com pesquisas das duplicações, acabando com o risco de gerar bugs a partir da prática de copiar e colar sem especializar o trecho, prevenindo bugs causados por esquecimento de uma atualização do trecho repetido em cada parte do sistema.

6 — Use constantes ao invés de números mágicos

É comum encontrar em métodos e outros trechos de código números fixos, sendo usados muitas vezes para comparação, cálculo, ou como limite numérico. Porém um número sozinho pode não expressar por si só o que representa no código. Isto é o que chamamos de número mágico.

Os números mágicos podem atrapalhar o entendimento geral de um trecho de código por não explicitar uma lógica de negócio ou o que ele representa. Imagine encontrar no código um número 1, 3 ou 7 perdidos e não saber o que eles significam? Agora imagina o tempo gasto para entender isso, ou o tempo buscando disponibilidade de alguém da área de negócio para talvez ajudar a entender algo a respeito? Esse tempo poderia ser otimizado com o uso de constantes e o esforço estaria inteiramente destinado a evolução da funcionalidade associada a este código.

Por que utilizar?

Substituir números mágicos por constantes ajuda a reduzir custos com manutenção de 3 maneiras:

• O que o número representa fica explícito no código, bastando apenas olhar o nome da constante;
• O próprio uso de uma constante mostra que aquele valor não mudará em tempo de execução, ele é sempre o mesmo, ou seja, fixo, só mudará por uma necessidade de negócio (quando, e se acontecer);
• Caso o número seja utilizado mais de uma vez no código ou em outros arquivos, a mesma constante pode ser utilizada por meio do reaproveitamento.

Utilizar constantes ajuda não somente por exprimir melhor a utilidade de tal número, também a detectar facilmente onde o número é utilizado. Também verificando se há outros números associados e entendendo o que representam em cada contexto, além de permitir o reaproveitamento.

Como essas técnicas ajudam a reduzir o custo de desenvolvimento e manutenção na prática?

Aumentando a eficiência na manutenção ou evolução de funcionalidades através de práticas que reduzem o tempo e esforço necessário de entendimento e implementação do “que” e do “como” será feito no código.

A produtividade dos times de engenharia de software também está associada à qualidade técnica dos projetos. E quanto menor a qualidade técnica, maior é o custo de manutenção.

De acordo com o artigo gerado a partir do estudo Clean Code: On the Use of Practices and Tools to Produce Maintainable Code for Long-Living Software, a escolha de procedimentos e práticas é mais cultural do que problema técnico.

Tendo isso em mente, o time que prioriza a adoção de práticas que aumentam a eficiência da manutenção e pensam no longo prazo, tendem a poupar futuras modernizações e dificuldades de evolução em funcionalidades existentes.

A aplicação do Clean Code incentiva uma atuação proativa focada em longo prazo. E seus resultados também podem ser comprovados através de uma comparação realizada com cenários que envolvem sistemas em que essas técnicas não foram aplicadas.

Clean Code investimento evolutivo

Sistemas de sucesso geralmente são medidos pela sua capacidade de adaptação e extensibilidade para permitir uma rápida evolução frente as necessidades de negócio e de mercado. Infelizmente a maioria dos sistemas são construídos sem que boas práticas e técnicas que facilitam a manutenção sejam consideradas.

Quanto mais bem sucedido é o sistema, por mais tempo será mantido e menos problemas enfrentará.

Em vista disso, para garantir que a manutenção de sistemas não se torne um grande problema para as empresas, trazendo custos com horas de manutenção que poderiam ser revertidas em evolução com foco no negócio, se faz necessária a aplicação de técnicas de Clean Code através de um processo contínuo e incremental.

Os ganhos da aplicação dessas técnicas podem ser comprovados e medidos de forma empírica no dia a dia conforme evolução dos sistemas que estão sendo desenvolvidos. E no final, o que se gasta financeiramente com manutenção, será investido com evolução.

Referências

Martin, Cecil Robert. Clean Code. 2008.
Clean Code: On the Use of Practices and Tools to Produce Maintainable Code for Long-Living Software