Refatoração de código legado em C++: do A ao Z

Introdução

Trabalhar com código legado em C++ é uma realidade inevitável para muitos desenvolvedores. Projetos antigos, escritos há 10-15 anos, frequentemente contêm construções obsoletas, macros, gerenciamento manual de memória e ausência de testes unitários. Refatorar esse código é uma tarefa nada fácil, mas extremamente necessária para manter a viabilidade do produto. Neste artigo, vamos detalhar um plano passo a passo para refatorar código C++ legado: desde a análise até a implementação de práticas modernas.

1. Preparação para a refatoração: análise e testes

1.1. Inventário da base de código

O primeiro passo é entender com o que você está lidando. Use ferramentas de análise estática, como Clang-Tidy, PVS-Studio ou Cppcheck, para identificar pontos problemáticos: vazamentos de memória, comportamento indefinido, padrões obsoletos.

// Exemplo de execução do Clang-Tidy\nclang-tidy main.cpp -- -std=c++17 -I./include

Crie um mapa de dependências dos módulos. Frequentemente, o código legado sofre de dependências cíclicas e "classes divinas".

1.2. Cobertura de testes

Sem testes, refatoração é jogar roleta-russa. Escreva testes de caracterização (characterization tests) que fixam o comportamento atual do sistema. Use frameworks como Google Test ou Catch2.

#include <gtest/gtest.h>\n\nTEST(LegacyModule, ProcessData_ShouldReturnExpected) {\n    LegacyClass obj;\n    int result = obj.ProcessData(42);\n    EXPECT_EQ(result, 84); // Fixa o comportamento atual\n}

Mesmo que o código pareça "incorreto", o teste deve refletir seu funcionamento real. Após a refatoração, os testes devem passar se você não alterou a lógica.

2. Modernização gradual: de macros para constexpr

2.1. Substituição de macros e #define

Macros são o flagelo do código legado. Elas não têm tipo, não obedecem a namespaces e dificultam a depuração. Substitua-as por constexpr, funções inline ou enum class.

// Antes da refatoração\n#define BUFFER_SIZE 256\n#define MAX(a, b) ((a) > (b) ? (a) : (b))\n\n// Após a refatoração\nconstexpr size_t BUFFER_SIZE = 256;\n\ntemplate<typename T>\nconstexpr T max(T a, T b) noexcept {\n    return (a > b) ? a : b;\n}

2.2. Melhoria do gerenciamento de memória

O gerenciamento manual de memória com new/delete é fonte de vazamentos e duplas liberações. Migre para ponteiros inteligentes (std::unique_ptr, std::shared_ptr) e contêineres STL.

// Antes da refatoração\nvoid process() {\n    Widget* w = new Widget();\n    // ... código ...\n    delete w; // fácil de esquecer em caso de exceção\n}\n\n// Após a refatoração\nvoid process() {\n    auto w = std::make_unique<Widget>();\n    // ... código ...\n    // remoção automática ao sair do escopo\n}

2.3. Eliminação de ponteiros e arrays crus

Substitua arrays no estilo C por std::array ou std::vector, e strings por std::string.

// Antes da refatoração\nvoid copy_data(char* dest, const char* src, size_t len) {\n    memcpy(dest, src, len); // risco de estouro de buffer\n}\n\n// Após a refatoração\nvoid copy_data(std::span<char> dest, std::span<const char> src) {\n    std::copy(src.begin(), src.end(), dest.begin());\n}

3. Mudanças estruturais: divisão e modularidade

3.1. Separação de "classes divinas"

Classes que fazem tudo (God Object) são um sinal claro de arquitetura ruim. Use o princípio da responsabilidade única (SRP). Separe classes específicas para manipulação de arquivos, logging, lógica de negócios.

// Antes: uma classe faz tudo\nclass MonsterManager {\n    void LoadFromFile(const std::string& path);\n    void Render();\n    void UpdateAI();\n    void SaveToDatabase();\n    /