Quando Me Preocupar com Qualidade de Código?

Ao nos depararmos com um código ruim, nós, desenvolvedores, lutamos para encontrar o caminho do esclarecimento, buscando alguma pista do que está acontecendo. Mas muitas vezes, tudo o que encontramos é um código cada vez mais sem sentido. Mesmo estando na pele de quem vaga por esse difícil caminho, a maior parte de nós já olhou para um código ruim e decidiu deixá-lo viver mais um dia.

O objetivo deste texto é trazer algumas reflexões para te motivar a considerar qualidade de código como um exercício diário de programação. Um segundo post com algumas dicas práticas e sugestões de melhorias de código será lançado em um futuro bem próximo.

No livro Clean Code, Robert Martin, um dos autores do Manifesto Ágil, afirma que todo desenvolvedor com alguma experiência já foi atrasado e prejudicado por um código ruim. Ele, inclusive, cita um caso real de uma empresa que fechou as portas graças a uma base de código inoperável, mesmo essa empresa tendo desenvolvido um produto inicialmente bastante promissor.

Martin então propõe a seguinte reflexão:

Por que continuamos escrevendo código ruim?

Frequentemente, a pressão para entregar novas funcionalidades faz com que muitos desenvolvedores reforcem o argumento de que não há tempo para trabalhar na qualidade do código da forma que gostariam. Porém, o aumento constante do número de tarefas no backlog não é a única justificativa que encontramos para não melhorar um código.

Muitas vezes é o gerente entortando o nariz quando a necessidade de continuar trabalhando em código que já funciona é enfatizada. Acontece também de só estarmos cansados de olhar pro mesmo código por tanto tempo — ou ainda, de só descobrimos a melhor solução depois de resolver o problema pela primeira vez.

Esse compilado de justificativas é a base de um dos debates mais comuns em desenvolvimento de software:

Devo eu gastar tempo melhorando a qualidade do código ou devo focar nas novas funcionalidades, agregando mais valor ao produto final?

Esse debate imediatamente nos remete ao nosso senso comum de custo benefício. No artigo “Is High Quality Software Worth the Cost?”, Martin Fowler apresenta uma discussão interessante ao questionar como o custo benefício se aplica ao desenvolvimento de software.

Fowler exemplifica que, ao trocar nosso smartphone, podemos escolher um modelo moderno, com um processador rápido, a melhor das telas e mais memória. Ou podemos abrir mão de algumas dessas qualidades em favor de pagar menos. Nesse exemplo, e em muitos outros exemplos do dia a dia, a regra geral se aplica: quanto melhor a qualidade, maior o preço.

Mas quando falamos de desenvolvimento de software, o cenário fica um pouco diferente.

O que acontece é que, tirando raras exceções, o código que você escreve vai ser lido por alguém. Esse alguém muitas vezes vai ser você mesmo, outras vezes vai ser o seu colega de time ou o desenvolvedor que der continuidade a esse software. Em geral, um programador está constantemente lendo código como parte do esforço de escrever código novo.

Voltando ao Clean Code

Robert Martin afirma que esta proporção pode chegar até a 10 para 1, ou seja, a cada dez linhas de código que lemos, escrevemos apenas uma. Como esta proporção é tão alta, faz sentido pensar que é essencial tornar um código o mais legível possível, mesmo que seja mais difícil escrevê-lo.

Uma vez que tornando o código fácil de ler, podemos concluir que você está facilitando a escrita de código novo.

Ou seja, estamos facilitando a vida do desenvolvedor que irá continuar trabalhando naquela base de código. E sabe aquela advertência “O próximo a usar pode ser você!” que, de vez em quando encontramos, principalmente, em locais públicos? Ela se aplica perfeitamente à escrita de código.

Portanto, alta qualidade de código diminui o custo de mudanças futuras. Mas esse esforço extra para escrever um bom código impõe também algum custo em curto prazo. E aí?

A realidade

Há de fato um período em que talvez não se importar com a qualidade do código seja mais produtivo. Durante esse período, existe um trade-off entre qualidade e custo. A real questão, então, se torna: quanto tempo dura esse período antes que as linhas se cruzem?

A maneira como Fowler encontrou de responder essa questão em seu artigo foi coletando a opinião de alguns de seus desenvolvedores de confiança.

Os desenvolvedores afirmam que o código de baixa qualidade os atrasa significativamente em apenas algumas semanas.

Isso significa que mesmo curtos esforços de desenvolvimento se beneficiam da atenção a boas práticas de programação.

Infelizmente, nós desenvolvedores geralmente não conseguimos justificar muito bem essa necessidade de atenção aos detalhes. E o que acaba acontecendo é que o código ruim resultante dificulta a vida dos desenvolvedores e custa dinheiro pro cliente.

Portanto, ao discutir qualidade de código, Fowler enfatiza que devemos abordar o assunto com esse viés totalmente econômico.

Afinal, somos nós a quem os usuários buscam para validar suas regras de negócio como um sistema. Somos nós que os gerentes de projeto procuram para ajudar a elaborar o cronograma. Somos cúmplices no planejamento do projeto e compartilhamos grande parte da responsabilidade por quaisquer falhas — especialmente se essas falhas tiverem a ver com código ruim.

A maioria dos gerentes quer a verdade quando nos procuram para saber quanto tempo precisamos para trabalhar em alguma tarefa. Eles querem um bom código, mesmo quando a preocupação com o cronograma nos passa a mensagem contrária.

Nossos gerentes podem defender o cronograma e os requisitos com entusiasmo, mas esse é o trabalho deles. O nosso trabalho é defender a qualidade do código com esse mesmo entusiasmo. Afinal, somos nós que sabemos que, no médio/longo prazo, o tempo investido em escrever um código de qualidade é muito menor do que o tempo de refactor e debugging de um código ruim.

Como escrever código limpo?

Como podemos garantir que o nosso código vai estar sempre atrás da porta certa? A segunda parte desse post trará dicas práticas e técnicas que podemos aplicar no nosso dia a dia como desenvolvedores. Por enquanto, eu irei apenas te indicar um possível caminho.

E esse caminho é: estudo e trabalho duro

Você deve adquirir o conhecimento dos princípios, padrões, boas práticas e heurísticas, e também deve triturar esse conhecimento em seus dedos, olhos e entranhas, estudando e praticando. O Clean Code é um excelente ponto de partida. O livro é um must read para desenvolvedores. Ele apresenta muita teoria além de vários estudos de caso de diferentes complexidades para você exercitar a limpeza de código.

Muitas pessoas tendem a pensar em um código ruim como algo que só ocorre quando as equipes de desenvolvimento são descuidadas e cometem erros, mas é importante observarmos que até as melhores equipes criam código bem longe do ideal.

Em geral, nossos projetos envolvem criar algo novo. Quase nunca nos deparamos com um problema bem entendido que já resolvemos diversas vezes anteriormente. Naturalmente, aprendemos mais sobre o problema enquanto construímos a solução. É bem comum ouvir que as equipes só entendem a melhor arquitetura para um software depois de passar um bom tempo construindo-o.

Escrever código, na realidade, é como qualquer outro tipo de escrita

Quando você escreve um artigo, um conto ou um romance, você coloca a tempestade de ideais em um papel e depois massageia a escrita até que o resultado seja uma leitura clara e envolvente. O primeiro rascunho pode ser desajeitado e desorganizado, então você o reestrutura e refina até que se leia da maneira que você deseja.

O que devemos ter em mente, então, é que as melhores equipes já se atentam às boas práticas durante o processo de escrita. Além disso, se preocupam em remover códigos ruins que foram acidentalmente criados, para possibilitar a adição de novas funcionalidades de forma rápida.

Bons times investem tempo criando bases de testes automatizados para que possam identificar bugs rapidamente. Eles refatoram o código com frequência, antes que um código ruim escale o suficiente para atrasar toda a equipe.

Senso de código

Escrever código limpo requer o uso disciplinado de algumas técnicas simples, como escolher nomes claros e suficientemente descritivos, evitar funções com centenas de linha de código, ou usar um linter para padronizar formatação, por exemplo.

Essas técnicas podem ser aplicadas através de um minucioso “senso de limpeza” ou “senso de código” adquirido. Esse “senso de código” é a chave. Alguns de nós nascemos com isso. Alguns de nós têm que se esforçar mais para adquiri-lo. Mas todos nós podemos alcançá-lo.

Um programador sem esse “senso de código” pode olhar para um módulo confuso e reconhecer a bagunça, mas não ter muitas ideias de como consertá-lo. Um programador com esse senso examinará um módulo confuso e verá opções e variações possíveis.

O “senso de código” ajudará o programador a escolher a melhor variação e o guiará para implementá-la. O ponto é que qualquer um pode desenvolver esse senso com estudo, prática e atenção aos detalhes.

E não basta escrever bem o código. O código deve ser mantido limpo ao longo do tempo. Todos nós já vimos código eventualmente deteriorar. Portanto, devemos assumir um papel ativo na manutenção da qualidade do código.

“Se todos nós fizermos o check-out do nosso código um pouco mais limpo do que quando o pegamos, o código simplesmente não irá deteriorar.” — Robert Martin

A limpeza não precisa ser algo grande. Mudar um nome de variável para um mais claro, dividir uma função grande em porções menores, eliminar um pequeno pedaço de código duplicado.

Você consegue se imaginar trabalhando em um projeto em que o código simplesmente melhora com o tempo que vai passando? Você acredita que qualquer outra opção é profissionalmente válida?

Na verdade, melhora contínua não é uma parte intrínseca do profissionalismo?

Dito isso, a resposta para a pergunta “Quando me preocupar com qualidade de código?” é sempre.