IGTI Blog
código

Melhoria de código: quando e por onde começar

Se produzir um código de alta qualidade já é um trabalho complexo, conseguir fazer uma gestão eficiente dos débitos técnicos garantindo que o código evolui ao longo do tempo é um grande desafio.

Nos cenários em que o cliente não paga explicitamente pela melhoria no código já existente, precisamos de uma boa estratégia de refatoração e melhoria contínua.

O que seria um código de alta qualidade? Provavelmente se perguntarmos a dez diferentes desenvolvedores, corremos o risco de receber respostas bem diferentes. Por outro lado, há uma série de convenções, principalmente as embasadas por autores e profissionais reconhecidos no mercado, que chegam perto de ser unanimidade.

Nesse cenário, é importante que cada empresa ou mesmo cada time ou projeto tente definir o que seria seu padrão de qualidade de código, se possível, com a obtenção de consensos entre os membros do time. Quando o consenso não é possível, acabamos optando pela opinião da maioria. Nessa discussão, é importante respeitarmos todas as opiniões, mesmo quando discordam das principais convenções. A argumentação é a chave para que os acordos funcionem. O que parece muito legível para um, pode não ser bom para outros.

código
Diferentes convenções e gostos. Fonte: Stackoverflow

Enquanto a discussão e a busca por consensos para definição dos padrões de qualidade do time não são fáceis, receber um sistema legado com os mesmos padrões de qualidade adotados pelo seu atual time é uma missão quase impossível. Talvez por isso seja tão comum ouvirmos a reclamação de desenvolvedores que o código dos outros é sempre tão ruim, por diferença nas convenções.

Seja por diferença nas convenções ou porque o código legado realmente foi mal programado, não podemos aceitar os chamados débitos técnicos. De forma bem resumida, os débitos técnicos são os problemas existentes no nosso código que o impedem de ter o padrão de qualidade esperado. Muitas vezes, durante o desenvolvimento de funcionalidades, optamos em desenvolver de uma forma que não seria a melhor. Isso poderia acontecer por uma série de fatores como restrição de orçamento ou tempo, por exemplo.

Nesses casos, deveríamos mapear esses débitos para que fossem corrigidos assim que possível. No caso do código legado, podemos fazer uma completa avaliação para identificar seus débitos técnicos ou mesmo registrar cada débito apenas quando for percebido, seja durante o uso do sistema, ou em manutenções corretivas ou evolutivas.

Em alguns casos, o cliente, ou quem paga pelo desenvolvimento sabe da importância da melhoria da qualidade e disponibiliza recursos e tempo dedicados à melhoria. Quando não encontramos um cenário assim, primeiramente, podemos tentar convencer o cliente a “comprar” a qualidade. Se não for possível, precisamos incluir a melhoria em suaves prestações em cada atividade desenvolvida. Aqui, já teríamos um padrão de qualidade definido, além de já saber o que precisamos desenvolver para o nosso sistema. Então quando e como começar?

Quando falamos de qualidade, quanto antes começarmos melhor. Outra grande verdade é que toda grande maratona começa com um pequeno passo. Levando essas considerações para a nossa realidade é importante que nosso processo de desenvolvimento de software, independente de qual seja, garanta que a cada tarefa ou ‘commit’ estejamos um pouco mais próximos do nosso padrão de qualidade, porém, se tentarmos começar com muita ambição, pode ser que a iniciativa acabe se perdendo no meio de outras prioridades. Então qual seria o pequeno passo nesse cenário?

Primeiramente, é preciso pensar no menor passo que se consegue dar na direção certa. Talvez seja corrigir um problema simples em uma linha de código do sistema legado a cada entrega, mas com certeza não seria corrigir todos os problemas de qualidade de uma grande classe a cada ‘commit’. Depois de definir o tamanho desse passo, comece a caminhada até apresentar consistência e confiança que o processo é confiável, que traz bons resultados e pode ser mantido. A cada novo ciclo (nova sprint, nova demanda ou novo projeto) podemos tentar dar um passo um pouco maior, mas sem nunca aumentar demais de uma só vez.

Um dos fatores mais importantes em uma jornada de transformação e ou melhoria contínua, é encontrar o ritmo correto da mudança. Mudanças muito lentas podem não ser reconhecidas e as muito rápidas não serão sustentáveis no médio e longo prazo. O que também é crucial é nunca dar passos para trás. Iniciativas que são descontinuadas acabam gerando mais descrença entre os membros do time, e a confiança no trabalho que está sendo feito é fundamental para o sucesso da abordagem.

Outro caminho importante a se percorrer é a busca por um bom embasamento conceitual. Vou citar livros clássicos que contribuem bastante nesse trabalho. O primeiro é o ‘Clean Code: A Handbook of Agile Software Craftsmanship’. Nele os autores argumentam conceitualmente a partir de casos bem práticos, servindo muito bem para desenvolvedores em qualquer nível da carreira. O segundo clássico é o ‘Refactoring: Improving the Design of Existing Code’. Nesse livro, Martin Fowler apresenta várias reflexões importantes, além de apresentar um grande número de exemplos práticos de códigos problemáticos com formas relacionadas para refatora-los. Robert Martin, que também é um dos autores do primeiro livro citado acima, foi quem definiu os princípios SOLID detalhados no ‘Agile Principles, Patterns, and Practices in C#’, outro marco entre os livros da área.

O IGTI também oferece uma série de opções para consolidar sua formação e garantir que tenha um embasamento sólido e saiba aplicá-lo em projetos complexos, mantendo uma alta qualidade de código.  Cursos de curta duração e MBAs estão disponíveis para fazer um upgrade na sua carreira.

E você, acredita na transformação da qualidade do código legado? Já conseguiu vencer essa grande inércia e mudar cenários que pareciam muito ruins? Fique à vontade para contribuir também.

Professor autor: Thiago Chierici Cunha