Realizar uma refatoração grande¹ de software não é algo simples. Há muitos pontos que você deve considerar, desde o planejamento e priorização até a motivação e execução da equipe. Entender esses pontos de forma estruturada e clara faz parte do processo. A boa notícia é que já passamos por essa situação antes e aprendemos quais os pontos principais com os quais você deve se preocupar.

Aqui estão os pontos principais que você deve considerar ao planejar e executar uma refatoração grande do seu sistema.

1. Defina metas de negócios

Uma refatoração grande de software não deve ser iniciada sem metas de negócios claras, caso contrário, você pode sofrer com a falta de comprometimento das partes interessadas. Aqui estão alguns exemplos de metas:

• O objetivo da refatoração é possibilitar a conexão de vários gateways de pagamento.
• O objetivo da refatoração é melhorar a velocidade de entrega.
• O objetivo da refatoração é viabilizar uma arquitetura multi-tenant para simplificar operações de infraestrutura.

2. Faça a medição do progresso

Em sua essência, o processo de refatoração de software é um esforço técnico, razão pela qual é comum não medir o progresso de forma estruturada, como é medido o progresso do desenvolvimento de novas features. Não caia nessa armadilha.

Assim como cada tarefa em um projeto, uma refatoração deve sempre ser planejada e medida.

3. Preste atenção à motivação da sua equipe

Trabalhar em base de código legado pode desmotivar os desenvolvedores, especialmente se não conseguem visualizar o progresso de suas atividades, ou se não sabem quando vão acabar. Ao passar por um processo de refatoração, você deve ter isso em mente.

Mostre à sua equipe que estão avançando. Planeje pequenas entregas, para viabilizar liberações contínuas e celebrar o bom trabalho feito. Além disso, pense em rotacionar os desenvolvedores para essa tarefa de refatoração, pois pode ajudar a manter a motivação.

4. Defina sua abordagem: puxada ou empurrada?

Você vai melhorar a base de código apenas quando encontrar um problema, ou escolherá de forma proativa as partes a melhorar?

Clique aqui para assistir o webinar Migração de Plataforma Tecnológica. É grátis!

5. Priorização

Se você tem uma meta de negócios clara, é mais fácil escolher proativamente as partes que precisam ser melhoradas para alcançar a meta. Com as partes listadas, você pode priorizar, como de costume.

Por outro lado, se você imagina que a base de código inteira deve ser refatorada, priorizar torna-se complicado, porque não há uma ou duas partes principais que precisam de melhorias, há muitas. É difícil saber por onde começar.

Uma solução é pedir ao time para avaliar a complexidade e churn do código para apontar as partes a refatorar. Para chegar numa conclusão se o código deve ou não ser refatorado, eles tem de se perguntar:

• A complexidade dessa classe é muito alta comparada às outras?
• Precisamos fazer mudanças constantes nesse arquivo?

Se ambas as respostas forem sim, essa parte do código parece um bom candidato para refatoração. Trace um gráfico de “complexidade de classe X churn”, priorize as partes que são mais complexas e que passam por alterações com frequência.

As partes do código que tem complexidade alta e que sofrem poucas modificações não são boas candidatas para serem refatoradas. Isso porque apesar de feias, funcionam. E também tem pouco impacto no desenvolvimento, já que a os desenvolvedores precisam modificá-las pouco no seu dia a dia.

6. Defina o “pronto”

O processo de refatoração de software pode se transformar em esforço infinito se você não planejar, priorizar e medir o progresso. Você deve tratá-lo como um projeto. Deve ter começo, meio e fim.

7. Cobertura da suíte de testes

A refatoração deve melhorar o que já está funcionando, sem quebrar nada. Certifique-se que a cobertura de testes está adequada, caso contrário, o processo pode gerar mais bugs do que melhorias de qualidade.

8. Desempenho da suíte de testes

Se a suíte de testes é lenta, refatorar também se tornará um processo lento, visto que a refatoração de software é fortemente baseada na execução contínua dos testes. Assegure que o desempenho da suíte de testes não seja um gargalo.

9. Compromisso dos patrocinadores

O processo de refatoração pode levar muito tempo: semanas, meses. Durante esse período, a velocidade das entregas de novas features será comprometida.

Certifique-se que stakeholders das áreas de negócio entendam os objetivos e a natureza desse tipo de trabalho para evitar que eles desistam no meio do caminho.

E você tem alguma dica além dessas para grande refatoração de software? Compartilhe conosco!

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

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

The post 9 Pontos-chaves ao se fazer uma refatoração grande de software first appeared on Plataformatec Blog.

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

The post Sintomas da Baixa Qualidade Interna de Software first appeared on Plataformatec Blog.