🔧 CAPÍTULO 18: MANUTENÇÃO E EVOLUÇÃO DE SOFTWARE


🎯 1. Objetivos de Aprendizagem & Competências

Estimativa de Dedicação: 2 horas de estudo autoguiado.
Ao final deste capítulo, você será capaz de:

  • 🔹 Classificar as 4 modalidades canônicas de manutenção segundo a norma ISO/IEC 14764: Corretiva, Adaptativa, Perfectiva e Preventiva.
  • 🔹 Compreender as Leis de Evolução de Software de Manny Lehman (Mudança Contínua, Complexidade Crescente, Declínio de Qualidade).
  • 🔹 Calcular e gerenciar o Débito Técnico (Technical Debt) utilizando a metáfora financeira de Ward Cunningham.
  • 🔹 Aplicar técnicas estruturadas de Refatoração de Código (Refactoring) catalogadas por Martin Fowler com a segurança de testes automatizados.

🏢 2. Cenário Corporativo & Estudo de Caso (TecProExpress)

Na TecProExpress, o módulo central de roteirização de entregas completou 4 anos em produção. No início, cada sprint entregava 10 novas funcionalidades; hoje, a equipe mal consegue entregar 2, gastando 80% do tempo apagando incêndios causados por bugs em código acoplado e sem documentação.

O Desafio: Como Engenheiro de Manutenção e Arquiteto de Software, você deve instituir uma política contínua de pagamento de débito técnico, reservando 20% da capacidade de cada sprint para refatoração preventiva e perfectiva (Boy Scout Rule: "Deixe o acampamento mais limpo do que você o encontrou").


🧠 3. Fundamentação Teórica & Modelos Visuais

3.1. As 4 Modalidades de Manutenção de Software (ISO/IEC 14764)

flowchart TD
    subgraph MANUTENCAO ["OS 4 TIPOS DE MANUTENÇÃO DE SOFTWARE"]
        C["🐛 1. MANUTENÇÃO CORRETIVA (Reativa)<br>Correção de bugs e falhas em produção."]
        A["🔄 2. MANUTENÇÃO ADAPTATIVA (Proativa/Reativa)<br>Adaptação a novos ambientes (migração de SO, nuvem, leis fiscais)."]
        P["✨ 3. MANUTENÇÃO PERFECTIVA (Proativa)<br>Melhoria de desempenho, refatoração de código e novas funcionalidades."]
        PR["🛡️ 4. MANUTENÇÃO PREVENTIVA (Proativa)<br>Correção de problemas latentes antes que se tornem incidentes reais."]
    end
    
    style C fill:#fee2e2,stroke:#ef4444
    style A fill:#e0f2fe,stroke:#0284c7
    style P fill:#dcfce7,stroke:#16a34a
    style PR fill:#fef3c7,stroke:#d97706

3.2. A Metáfora do Débito Técnico (Ward Cunningham)

Fazer alterações rápidas e "gambiarras" para bater prazos é como contrair um empréstimo financeiro: traz liquidez no curto prazo, mas acumula juros na forma de complexidade. Se o principal não for pago através de refatoração, a taxa de entrega da equipe cai a zero.

flowchart LR
    ATALHO["⚡ Atalho de Código / Sem Testes<br>(Empréstimo Rápido)"] --> DUIDA["📈 Débito Técnico Acumulado"]
    DUIDA --> JUROS["💸 Juros Mensais:<br>Bugs Frequentes & Entregas Lentas"]
    JUROS --> FALENCIA["⛔ Falência do Software / Reescrever do Zero"]
    
    DUIDA -.->|Refatoração Contínua| PAGO["✅ Débito Pago & Código Sustentável"]
    
    style ATALHO fill:#fef3c7,stroke:#d97706
    style DUIDA fill:#fee2e2,stroke:#ef4444
    style FALENCIA fill:#b91c1c,stroke:#7f1d1d,color:#fff
    style PAGO fill:#dcfce7,stroke:#16a34a

💻 4. Aplicação Prática & Código Executável (Python 3.11+)

📋 Pré-requisitos e Instalação

Este exemplo utiliza os recursos nativos do Python (decimal), sem necessidade de pacotes externos:

python --version  # Requer Python 3.11 ou superior

💻 Código Completo e Autocontido (refatoracao_exemplo.py)

Exemplo prático de Refatoração Perfectiva aplicando Guard Clauses, eliminação de aninhamento excessivo (Arrow Anti-Pattern) e tipagem estrita:

"""
Módulo: refatoracao_exemplo.py
Domínio: Aplicação do padrão Guard Clauses e eliminação de duplicação.
"""
from decimal import Decimal

# --- CÓDIGO ANTES DA REFATORAÇÃO (Espaguete / Alta Complexidade) ---
def calcular_desconto_legado(cliente_tipo, valor_total, dias_atraso):
    resultado = 0
    if valor_total > 100:
        if dias_atraso == 0:
            if cliente_tipo == "VIP":
                resultado = valor_total * 0.15
            else:
                resultado = valor_total * 0.05
        else:
            resultado = 0
    else:
        resultado = 0
    return resultado

# --- CÓDIGO APÓS A REFATORAÇÃO PERFECTIVA (Clean Code / Baixa Complexidade) ---
def calcular_desconto_refatorado(cliente_tipo: str, valor_total: Decimal, dias_atraso: int) -> Decimal:
    """Refatoração com Guard Clauses e tipagem estrita."""
    if valor_total <= Decimal("100.00") or dias_atraso > 0:
        return Decimal("0.00")
    
    taxa = Decimal("0.15") if cliente_tipo.upper() == "VIP" else Decimal("0.05")
    return (valor_total * taxa).quantize(Decimal("0.01"))

if __name__ == "__main__":
    print("--- Comparativo de Refatoração: Legado vs. Guard Clauses ---")
    
    # Caso 1: VIP adimplente > R$ 100
    v_antes = calcular_desconto_legado("VIP", 200, 0)
    v_depois = calcular_desconto_refatorado("VIP", Decimal("200.00"), 0)
    print(f"Caso 1 [VIP, R$ 200, sem atraso]: Legado = R$ {v_antes:.2f} | Refatorado = R$ {v_depois:.2f}")
    assert v_antes == float(v_depois)

    # Caso 2: Padrão adimplente > R$ 100
    v_antes_padrao = calcular_desconto_legado("PADRAO", 200, 0)
    v_depois_padrao = calcular_desconto_refatorado("PADRAO", Decimal("200.00"), 0)
    print(f"Caso 2 [Padrão, R$ 200, sem atraso]: Legado = R$ {v_antes_padrao:.2f} | Refatorado = R$ {v_depois_padrao:.2f}")
    assert v_antes_padrao == float(v_depois_padrao)

    # Caso 3: Cliente com atraso
    v_atraso = calcular_desconto_refatorado("VIP", Decimal("500.00"), 3)
    print(f"Caso 3 [VIP, com 3 dias de atraso]: Desconto = R$ {v_atraso:.2f}")
    assert v_atraso == Decimal("0.00")

    print("✅ Todos os comportamentos preservados com sucesso após a refatoração!")

🚀 Como Executar

Execute o script diretamente no terminal:

python refatoracao_exemplo.py

🖥️ Saída Esperada no Terminal

--- Comparativo de Refatoração: Legado vs. Guard Clauses ---
Caso 1 [VIP, R$ 200, sem atraso]: Legado = R$ 30.00 | Refatorado = R$ 30.00
Caso 2 [Padrão, R$ 200, sem atraso]: Legado = R$ 10.00 | Refatorado = R$ 10.00
Caso 3 [VIP, com 3 dias de atraso]: Desconto = R$ 0.00
✅ Todos os comportamentos preservados com sucesso após a refatoração!

💡 5. Checkpoint de Engenharia & Boas Práticas

Boas Práticas & Anti-Patterns

  • Refatoração com Rede de Segurança: Nunca refatore código que não possui testes automatizados. Primeiro crie os testes de caracterização para garantir que o comportamento atual não mude; depois limpe o código.
  • Anti-Pattern Reescrever do Zero (Second-System Effect): Evite a tentação de "jogar tudo fora e fazer de novo". Sistemas novos descartam anos de correções de casos de borda já resolvidos no legado. Refatore progressivamente (Strangler Fig Pattern).

🔗 6. Conexão com os Projetos Integradores

Projeto IntegradorComo o conceito deste capítulo é aplicado no PI
PI-02: StockFlowManutenção Adaptativa: migração transparente do motor de banco de dados SQLite (Dev) para PostgreSQL (Prod).
PI-06: ServiceFlowRefatoração Perfectiva: extração do cálculo de SLA para um serviço desacoplado e reutilizável.

🧪 7. Quiz de Fixação e Autoavaliação (Formative Assessment)

🧪 Quiz de Autoavaliação — Capítulo 18

1. A atividade de modificar o código interno de um software para torná-lo mais legível, modular e manutenível, SEM alterar em nada o seu comportamento externo observável, é denominada:

  • A) Manutenção Corretiva de Emergência.
  • B) Refatoração de Código (Refactoring / Manutenção Perfectiva).
  • C) Engenharia Reversa Ilícita.
  • D) Deploy Contínuo.
💡 Ver Resposta e Justificativa

Resposta Correta: B
Justificativa: Como definido por Martin Fowler, refatoração é a melhoria disciplinada do design interno do software sem alterar suas funcionalidades externas perceptíveis.


2. A 2ª Lei de Evolução de Software de Lehman (Complexidade Crescente) afirma que:

  • A) O custo dos servidores cai pela metade a cada 18 meses.
  • B) À medida que um sistema evolui, sua complexidade aumenta continuamente, a menos que esforços ativos de refatoração e simplificação sejam realizados para mantê-la sob controle.
  • C) O número de desenvolvedores deve dobrar a cada ano.
  • D) O software nunca deve receber novas funcionalidades.
💡 Ver Resposta e Justificativa

Resposta Correta: B
Justificativa: Lehman demonstrou que a adição de código sem refatoração degrada a estrutura do software com o tempo (entropia crescente), exigindo manutenção preventiva constante.


3. Uma alteração realizada no software para compatibilizá-lo com uma nova versão do PostgreSQL ou com uma nova lei tributária é classificada como:

  • A) Manutenção Corretiva.
  • B) Manutenção Adaptativa.
  • C) Manutenção Destrutiva.
  • D) Manutenção Estática.
💡 Ver Resposta e Justificativa

Resposta Correta: B
Justificativa: A manutenção adaptativa modifica o sistema para que ele continue operando corretamente frente a alterações no ambiente tecnológico ou regulatório externo.


🛠️ 8. Ponte para a Ação: Laboratório Prático

🎯 Próximo Passo Prático

Coloque esta teoria em prática executando o roteiro de laboratório autoguiado:
👉 ATIVIDADE 13: ARQUITETURA DE SOFTWARE E PADRÕES


📌 9. Resumo Executivo & Key Takeaways

  • 4 Tipos de Manutenção: Corretiva (Bugs), Adaptativa (Ambiente), Perfectiva (Qualidade/Refatoração) e Preventiva (Previsão de Falhas).
  • Débito Técnico: Metáfora que quantifica o custo oculto de atalhos e decisões de engenharia de baixa qualidade.
  • Leis de Lehman: O software degrada naturalmente a menos que receba investimentos contínuos de refatoração.
  • Boy Scout Rule: Manter o hábito diário de limpar e melhorar pequenos trechos de código em cada commit.