Engenharia de Software

Evolução, Manutenção e Refatoração de Software

Professor: Gabriel Soares Baptista

Por que essa aula importa?

Entregar um sistema não encerra o trabalho de engenharia de software.

Ideia central do Sommerville

Segundo Sommerville, desenvolvimento e evolução fazem parte do mesmo ciclo de vida.

Reflita

Software útil precisa mudar

Manutenção não é apenas correção de bugs.

Evolução em espiral

O ambiente força a evolução

A mudança pode vir de:

• novas regras de negócio
• mudanças legais ou regulatórias
• defeitos encontrados em operação
• atualização de sistema operacional, banco ou hardware
• integração com outros sistemas
• novas expectativas dos usuários
• pressão competitiva do mercado

Exemplos de ambiente mudando

Sistema de biblioteca:

• renovação pelo aplicativo
• nova regra de multa
• login institucional único
• relatório para sistema nacional

Cuidado importante

Do desenvolvimento para a evolução

Separar rigidamente desenvolvimento e manutenção pode esconder o custo real da vida do sistema.

Evolução, serviço e fim gradual

Exemplo: evolução ou serviço?

Folha de pagamento:

• recebe ajustes anuais de regras, relatórios e integrações
• ainda está em evolução

Processo de evolução

Toda evolução começa com uma proposta de mudança.

Ela pode vir de bug, novo requisito, necessidade operacional ou melhoria sugerida pela equipe.

Perguntas antes de mudar

Antes de implementar, a equipe deve perguntar:

1. o que precisa mudar?
2. que partes do sistema serão afetadas?
3. quanto custará implementar e testar?
4. em qual release a mudança deve entrar?

Análise de impacto

Análise de impacto é entender as consequências de uma mudança antes de implementá-la.

Exemplos de análise de impacto

CPF obrigatório no responsável financeiro:

• tabela de responsáveis
• registros antigos sem CPF
• tela de cadastro
• validação na API
• relatórios financeiros
• testes e integrações externas

Correções emergenciais

Às vezes, um defeito grave em produção exige correção rápida.

Leis de Lehman

Lehman e Belady estudaram a evolução de sistemas de grande porte.

O alerta das leis

As leis não são fórmulas matemáticas rígidas.

Exemplos das leis em ação

Sistema de atendimento que cresce:

• chat, WhatsApp, relatórios, automações e permissões especiais
• se tudo entra no lugar mais rápido, surgem regras duplicadas e condicionais espalhadas

Tipos de manutenção

Mito sobre manutenção

Por que manutenção custa caro?

Adicionar funcionalidade depois que o sistema está em operação costuma ser mais caro porque a equipe precisa:

• entender decisões antigas
• lidar com documentação incompleta
• trabalhar sobre estrutura possivelmente degradada
• preservar dados reais
• proteger funcionalidades existentes com testes
• evitar quebrar integrações externas

Problema organizacional

Contratos de desenvolvimento e manutenção muitas vezes são separados.

Exemplos de custo de manutenção

Regra duplicada:

• mensalidade copiada em três módulos para entregar rápido
• depois, a manutenção precisa encontrar, alterar e testar todas as cópias

Previsão de manutenção

Gerentes tentam prever manutenção para evitar surpresas de orçamento e prazo.

Métricas úteis:

• solicitações corretivas
• tempo médio de análise de impacto
• tempo médio para implementar mudança
• solicitações pendentes
• complexidade de componentes críticos

Métrica ajuda, mas não decide sozinha

Reengenharia de software

Quando um sistema legado ainda tem valor, mas se tornou difícil de mudar, uma opção é aplicar reengenharia.

O que pode entrar na reengenharia?

• tradução de código-fonte
• engenharia reversa
• melhoria da estrutura do programa
• modularização
• reengenharia de dados

Reengenharia não é reescrita total

Reescrever um sistema crítico do zero pode parecer atraente, mas envolve alto risco.

Benefícios destacados por Sommerville:

• risco reduzido
• custo reduzido

Exemplos de reengenharia

Sistema COBOL com regras acumuladas:

• exige engenharia reversa, documentação de regras, testes e modularização gradual

Refatoração como manutenção preventiva

Refatoração é melhorar a estrutura interna do código sem alterar o comportamento observável.

Refatoração depende de testes

Refatoração conversa diretamente com a aula de testes.

Refatoração x reengenharia

Maus cheiros de código

Fowler, citado por Sommerville, chama de maus cheiros os sinais de que o código pode precisar de refatoração.

Exemplos:

• código duplicado
• métodos longos
• condicionais complexas ou repetidas
• grupos de dados repetidos
• generalidade especulativa

Exemplo: código duplicado

Antes:

def calcular_total_carrinho(valor):
    frete = 0 if valor >= 200 else 15
    return valor + frete

def simular_pagamento(valor):
    frete = 0 if valor >= 200 else 15
    return {"total": valor + frete}

Depois:

def calcular_frete(valor):
    return 0 if valor >= 200 else 15

Exemplo: método longo

Antes, uma função pode misturar validação, cálculo e montagem de resposta.

Depois, a refatoração separa responsabilidades:

def validar_pedido(cliente, itens):
    if cliente is None or len(itens) == 0:
        raise ValueError("pedido invalido")

def calcular_subtotal(itens):
    return sum(item["preco"] * item["quantidade"] for item in itens)

def calcular_frete(total):
    return 0 if total >= 200 else 15

Sistemas legados

Sistemas legados são sistemas antigos que continuam importantes para a organização.

Avaliação de sistemas legados

Sommerville propõe avaliar legados por duas perspectivas:

1. valor de negócio
2. qualidade do sistema

Matriz de decisão

O que avaliar?

Valor de negócio:

• uso em momentos críticos, apoio a processos centrais, importância das saídas e impacto de falhas

Exemplos de decisão em legados

Sistema antigo de boletos:

• usado diariamente, falha afeta o caixa, código difícil e biblioteca sem suporte
• alto valor e baixa qualidade: reengenharia ou substituição gradual

Responsabilidade profissional

Engenheiros de software têm responsabilidade profissional de produzir código que possa ser mantido e alterado.

Ideia final

Próximos passos

Avaliação!