Primeiro post da série Baixa Qualidade Interna de Software

Não só bens físicos se deterioram, isso também ocorre com software.

Todos sabem que bens físicos se deterioram. As pessoas aceitam este fato e sempre lidaram com isso. O que as pessoas não aceitam tão facilmente é que software “se deteriora” também. Ao contrário dos bens físicos, isso não acontece devido a algum fenômeno físico ou químico. Essa deterioração ocorre geralmente devido a mudanças de negócios ou de profissionais. Vou dar um exemplo.

Imagine que você é o líder de uma equipe de produto ou tecnologia em uma startup; você é o CTO. Você já lançou a primeira versão do seu produto e foi um sucesso. Seu modelo de negócio foi validado e agora você está em fase de crescimento. Isso é fantástico! Mas tem seus custos, além de novos desafios.

A primeira versão do seu produto está funcionando, mas a base de código não está como você precisa a partir de agora. Talvez sua equipe não seja tão veloz quanto antes. Sua equipe reclama continuamente da qualidade do código. O CEO e o diretor de produto querem novas features e suas estimativas atuais não atenderão às necessidades do negócio.

Não raro, baixa qualidade da base de código está entre as principais origens de todos problemas. Talvez você precise refatorar (refactor) ou reescrever (rewrite) o software.

Quando a base de código não está em boas condições, todos podem ficar frustrados.

Sua equipe inteira, incluindo os desenvolvedores, se sentirão frustrados porque gostariam de liberar features com maior velocidade, porém a qualidade do código e a arquitetura atual não ajudam.

Os departamentos de TI, produto e software sofrem por não atenderem às expectativas das outras áreas.

O cliente também sofre devido aos bugs frequentes, o tempo gasto para que sejam corrigidos, além da demora para lançar novas features.

Você conseguiu entender.

Identifique os sintomas

É papel do líder (por exemplo, o CTO) identificar quando é necessário refatorar ou reescrever o software. Para isso, ele(a) pode fazer uma análise em busca de alguns sintomas, como os listados abaixo:

• Tudo é difícil: Quase todas features novas ou correções de bugs que sua equipe precisa fazer são difíceis. Nem sempre foi assim. Você se lembra dos bons tempos em que sua equipe era rápida e a execução era perfeita.
• Velocidade lenta: a velocidade de sua equipe diminuiu ou está diminuindo. Quando vocês desenvolveram a primeira versão do produto, era rápido desenvolver uma nova feature. Sua equipe conseguia desenvolver um monte delas a cada iteração. Agora é diferente.
• Suíte de testes lenta: Sua suíte de testes apresenta tempo de execução 10x, 20x, 30x maior que antes.
• Bugs que não desaparecem: Sua equipe corrige um bug e em algumas semanas ele reaparece. É comum sua equipe corrigir bugs em testes de regressão.
• Sua equipe está desmotivada: Sua equipe reclama continuamente que trabalhar no projeto já não é tão produtivo como era no antes. Uma pessoa não consegue construir uma feature sozinha; há muitas partes em movimento.
• Conhecimento isolado: Existem algumas partes do software que apenas um desenvolvedor conhece bem o suficiente para mantê-las. O resto da equipe tem dificuldades em trabalhar com esse código específico.
• O período de adaptação de um novo desenvolvedor é muito longo: Quando novos desenvolvedores se juntam à equipe, demora demais para que eles se tornem totalmente produtivos.

A razão pela qual você está em uma dessas situações provavelmente não é técnica. Talvez você precisasse entregar muitas features muito rápido, enquanto ainda estava desenvolvendo a primeira versão de seu produto. Talvez sua equipe não tinha maturidade e experiência que possuem agora. Analisar a causa raiz também é importante, mas você precisa fazer mais. Você precisa resolver o seu problema.

Se você está enfrentando os sintomas acima, provavelmente você tem problema de baixa qualidade interna de software. Reconhecer os sintomas já é um grande passo. O próximo passo é pensar em soluções. Algumas soluções que você pode considerar incluem o processo de refatorar ou reescrever o software.

Refatorar ou reescrever?

Não existe um guia definitivo que aponte quando você deve refatorar ou reescrever o software, pois depende muito do seu contexto. Dito isto, existem algumas regras básicas que você deve considerar ao avaliar qual a melhor solução para sua situação:

Quando reescrever

• Se a tecnologia que você usa está desatualizada e não possui mais manutenção;
• Se seu software é muito lento e mudar a arquitetura não é suficiente ou viável;
• Se a disponibilidade de desenvolvedores de software que conhecem a tecnologia que você usa é baixa e está diminuindo;
• Se existem novas tecnologias que oferecem vantagem significativa em relação a que você utiliza.

Quando refatorar

• Se a tecnologia que você usa ainda possui manutenção e é relevante;
• Se é viável melhorar seu aplicativo gradualmente;
• Se o problema que você está resolvendo é apenas técnico, e não de negócio.

Não é fácil decidir qual opção escolher. Ao optar por uma delas, você enfrentará um monte de novas preocupações. Fique atento, em nossos próximos posts vamos discutir o que levar em consideração antes de optar por refatoração ou reescrita do software.

Agora eu gostaria de saber sobre suas experiências. Você já esteve nessa situação? Como você identificou que o problema era baixa qualidade interna de software? Compartilhe sua história conosco!

Leia os outros posts da série Baixa Qualidade Interna de Software

1. Sintomas da Baixa Qualidade Interna de Software você está lendo
2. 9 Pontos-chaves ao se fazer uma refatoração grande de software
3. 8 pontos-chaves para reescrever um software