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

Introdução9.1

Hoje você vai ver por que entregar um sistema não encerra o trabalho de engenharia de software. Na prática, a entrega apenas muda o tipo de problema que a equipe passa a enfrentar.

Até aqui, estudamos processos, requisitos, modelos, arquitetura, implementação e testes. Todos esses temas aparecem antes da primeira entrega, mas continuam importando depois dela. O motivo é simples: um software útil entra em contato com um ambiente real, e esse ambiente muda. A organização muda suas regras, usuários descobrem novas necessidades, plataformas são atualizadas, defeitos aparecem em produção e outros sistemas passam a exigir integração.

Segundo Sommerville, essa é a razão para tratarmos desenvolvimento e evolução como partes de um mesmo ciclo de vida. Um sistema profissional raramente é construído, entregue e abandonado. Ele continua sendo modificado enquanto ainda tiver valor para a organização.

Provavelmente não. Mesmo que o código original estivesse correto, o sistema pode ficar progressivamente menos útil se não acompanhar o ambiente. Essa é a ideia central da evolução de software.

Software útil precisa mudar9.2

Um erro comum é imaginar manutenção como uma atividade menor, feita apenas para corrigir bugs. Isso reduz demais o problema. Em sistemas reais, manutenção também inclui adaptação a novos ambientes, incorporação de novos requisitos, melhoria de estrutura e preparação para mudanças futuras.

Sommerville destaca que sistemas de software são ativos críticos de negócio. Uma organização pode depender deles para vender, atender clientes, controlar estoque, operar infraestrutura ou cumprir obrigações legais. Por isso, preservar o valor desses sistemas costuma consumir uma parte enorme do orçamento de TI.

A Figura 9.1 ajuda a enxergar a ideia de ciclo. O sistema passa por especificação, implementação, validação e operação, mas isso não acontece uma única vez. Depois do primeiro release, novas mudanças alimentam outro ciclo, que produz outro release, e assim por diante.

O ambiente força a evolução9.2.1

A mudança pode vir de muitos lugares:

1. novas regras de negócio;
2. mudanças legais ou regulatórias;
3. defeitos encontrados em operação;
4. atualização de sistema operacional, banco de dados ou hardware;
5. integração com outros sistemas;
6. novas expectativas dos usuários;
7. pressão competitiva do mercado.

Essa variedade importa porque mostra que a manutenção não é apenas um problema técnico. Ela é também uma resposta a mudanças organizacionais, econômicas e sociais.

Do desenvolvimento para a evolução9.3

Sommerville propõe pensar o software como um processo contínuo. Em vez de separar rigidamente "desenvolvimento" e "manutenção", faz mais sentido enxergar ambos como ciclos de mudança.

Essa mudança de visão é importante porque combate uma ideia perigosa: a de que a equipe pode economizar durante o desenvolvimento e deixar a manutenibilidade para depois. Na prática, depois costuma ser mais caro. Quando o sistema já está em produção, a equipe precisa entender o código existente, avaliar impactos, preservar dados, evitar regressões e negociar mudanças com usuários reais.

Evolução e serviço9.3.1

Rajlich e Bennett, citados por Sommerville, distinguem fases diferentes na vida de um sistema:

1. desenvolvimento inicial, quando o sistema é criado;
2. evolução, quando mudanças significativas ainda são feitas;
3. em serviço, quando apenas mudanças pequenas e essenciais são aceitas;
4. interrupção gradual, quando o sistema ainda pode ser usado, mas deixa de receber novas mudanças relevantes.

Essa distinção mostra que nem todo sistema em uso está igualmente saudável. Alguns sistemas continuam evoluindo com relativa segurança. Outros ainda são usados, mas já estão tão rígidos ou arriscados que a organização apenas evita mexer neles.

O processo de evolução9.4

Toda evolução começa com alguma proposta de mudança. Essa proposta pode vir de um bug, de um novo requisito, de uma necessidade operacional ou de uma melhoria sugerida pela equipe. O ponto essencial é que a mudança não deve ser simplesmente implementada sem análise.

A Figura 9.4 mostra um fluxo típico. Uma solicitação de mudança passa por análise de impacto, planejamento de release, implementação e liberação do sistema. Esse processo tenta responder quatro perguntas práticas:

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

Análise de impacto9.4.1

A análise de impacto é a tentativa de entender as consequências de uma mudança antes de implementá-la. Ela exige examinar código, requisitos, arquitetura, testes, dados, interfaces e integrações.

Essa etapa é decisiva porque uma mudança pequena na tela pode esconder uma alteração grande no domínio. Uma mudança aparentemente localizada pode afetar banco de dados, regras de validação, relatórios e APIs externas.

Podem ser afetados o banco de dados, validações, importações, exportações, relatórios, testes automatizados, documentação, integrações, permissões e até regras de negócio que usam aquele cadastro.

Correções emergenciais9.4.2

Sommerville também chama atenção para um caso perigoso: a correção emergencial. Às vezes, um defeito grave em produção precisa ser corrigido rapidamente. Nessa situação, a equipe pode pular parte do fluxo formal e aplicar uma solução viável no código.

Isso pode ser necessário, mas tem custo. Se a documentação, os requisitos e os testes não forem realinhados depois, o sistema envelhece mais rápido. A solução emergencial vira uma decisão permanente sem análise adequada.

As leis de Lehman e a dinâmica da evolução9.5

Lehman e Belady estudaram a evolução de sistemas de software de grande porte e propuseram leis que descrevem padrões observados ao longo do tempo. A ideia mais importante para esta aula é que sistemas usados no mundo real não ficam parados.

Sommerville destaca algumas leis particularmente úteis para raciocinar sobre manutenção:

Essas leis não devem ser lidas como fórmulas matemáticas rígidas. Elas funcionam melhor como alertas gerenciais e técnicos. Se uma equipe adiciona funcionalidade continuamente sem refatorar, testar e reorganizar, a complexidade tende a crescer.

Tipos de manutenção de software9.6

Sommerville organiza a manutenção em três tipos principais. A distinção é útil, mesmo que na prática os casos se misturem.

A Figura 9.7 é especialmente importante para desfazer um mito. A maior parte do esforço de manutenção não costuma estar na correção de defeitos. No exemplo apresentado por Sommerville, a maior fatia está na adição ou modificação de funcionalidade.

Por que manutenção custa caro9.6.1

Adicionar uma funcionalidade depois que o sistema está em operação costuma ser mais caro do que adicioná-la durante o desenvolvimento inicial. Isso acontece por vários motivos:

1. a equipe original pode ter sido desmobilizada;
2. a nova equipe precisa entender decisões antigas;
3. a documentação pode estar incompleta ou desatualizada;
4. o sistema pode ter estrutura degradada;
5. os testes precisam proteger funcionalidades já existentes;
6. dados reais precisam ser preservados;
7. integrações externas podem ser afetadas.

Sommerville também destaca um problema organizacional: contratos de desenvolvimento e manutenção muitas vezes são separados. Isso reduz o incentivo para a equipe inicial investir em manutenibilidade, porque o custo da má estrutura será pago por outra equipe ou por outro orçamento.

Previsão de manutenção9.7

Gerentes tentam prever manutenção porque mudanças inesperadas podem consumir orçamento e atrasar entregas. A previsão envolve estimar quais partes do sistema provavelmente mudarão, quais serão caras de manter e quanto esforço será necessário em determinado período.

Sommerville sugere observar tanto o ambiente quanto o próprio sistema. Partes mais expostas a mudança tendem a ter mais interfaces, requisitos voláteis ou forte dependência de processos de negócio instáveis.

Algumas métricas úteis são:

1. número de solicitações de manutenção corretiva;
2. tempo médio de análise de impacto;
3. tempo médio para implementar uma solicitação de mudança;
4. número de solicitações de mudança pendentes;
5. complexidade de componentes críticos.

Reengenharia de software9.8

Quando um sistema legado ainda tem valor, mas se tornou difícil de entender e modificar, uma opção é aplicar reengenharia. O objetivo é melhorar sua estrutura, documentação e inteligibilidade sem mudar sua funcionalidade essencial.

A Figura 9.10 apresenta um processo geral de reengenharia. Ele pode envolver tradução de código-fonte, engenharia reversa, melhoria da estrutura do programa, modularização e reengenharia de dados.

Reengenharia não é reescrita total9.8.1

Reengenharia e substituição completa são decisões diferentes. Reescrever um sistema crítico do zero pode parecer atraente, mas envolve alto risco. A equipe pode não entender todas as regras implícitas do sistema antigo, pode repetir erros de especificação e pode atrasar a entrega do novo sistema.

Sommerville destaca dois benefícios da reengenharia em relação à substituição:

1. risco reduzido, porque o sistema existente já incorpora conhecimento operacional;
2. custo reduzido, porque melhorar o sistema pode ser mais barato do que reconstruí-lo completamente.

Mas há limites. Reengenharia não transforma magicamente um sistema antigo em um sistema moderno perfeito. Grandes mudanças arquiteturais e reorganizações profundas de dados continuam sendo caras e difíceis.

Refatoração como manutenção preventiva9.9

Refatoração é o processo de melhorar a estrutura interna do código sem alterar seu comportamento observável. Ela não adiciona funcionalidade. Ela torna o código mais claro, menos duplicado, menos acoplado ou mais fácil de modificar.

Sommerville apresenta a refatoração como uma forma de manutenção preventiva. A ideia é simples: se a estrutura degrada com mudanças sucessivas, então a equipe precisa investir continuamente em pequenas melhorias estruturais para evitar que o custo futuro exploda.

Essa ideia conversa diretamente com a aula de testes. Refatorar com segurança depende de testes de regressão. Se os testes antes passavam e continuam passando depois da refatoração, a equipe ganha confiança de que melhorou a estrutura sem mudar o comportamento.

Reengenharia e refatoração não são a mesma coisa9.9.1

Maus cheiros de código9.9.2

Fowler, citado por Sommerville, usa a expressão maus cheiros para indicar sinais de que o código pode precisar de refatoração. Alguns exemplos são:

1. código duplicado;
2. métodos longos;
3. condicionais complexas ou repetidas;
4. grupos de dados que aparecem juntos em vários lugares;
5. generalidade especulativa, quando a equipe cria abstrações para um futuro que talvez nunca chegue.

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


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

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


def calcular_total_carrinho(valor):
    return valor + calcular_frete(valor)


def simular_pagamento(valor):
    return {"total": valor + calcular_frete(valor)}

def fechar_pedido(cliente, itens):
    if cliente is None:
        raise ValueError("cliente obrigatorio")
    if len(itens) == 0:
        raise ValueError("pedido vazio")

    total = 0
    for item in itens:
        total += item["preco"] * item["quantidade"]

    if total >= 200:
        frete = 0
    else:
        frete = 15

    return {
        "cliente": cliente["nome"],
        "total": total + frete,
        "frete": frete,
    }

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


def calcular_subtotal(itens):
    total = 0
    for item in itens:
        total += item["preco"] * item["quantidade"]
    return total


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


def fechar_pedido(cliente, itens):
    validar_pedido(cliente, itens)
    subtotal = calcular_subtotal(itens)
    frete = calcular_frete(subtotal)

    return {
        "cliente": cliente["nome"],
        "total": subtotal + frete,
        "frete": frete,
    }

Sistemas legados e decisões estratégicas9.10

Sistemas legados são sistemas antigos que continuam importantes para a organização. O problema não é simplesmente a idade. Um sistema antigo pode ser estável, bem documentado e barato de manter. O problema aparece quando ele tem alto valor de negócio, mas baixa qualidade técnica, dependências obsoletas ou manutenção cara.

Sommerville propõe avaliar sistemas legados por duas perspectivas:

1. valor de negócio, que indica quanto o sistema contribui para processos importantes;
2. qualidade do sistema, que inclui qualidade da aplicação e do ambiente técnico.

A Figura 9.12 organiza a decisão em uma matriz. O cruzamento entre valor de negócio e qualidade técnica ajuda a escolher a estratégia.

O que avaliar em um legado9.10.1

Para avaliar o valor de negócio, algumas perguntas são fundamentais:

1. o sistema é usado por muitas pessoas ou em momentos críticos?
2. ele apoia processos centrais do negócio?
3. suas saídas são importantes para decisões ou operações?
4. falhas nele afetam clientes, receita, segurança ou obrigações legais?

Para avaliar a qualidade técnica, observe fatores como:

1. inteligibilidade do código;
2. documentação disponível;
3. qualidade e consistência dos dados;
4. desempenho;
5. linguagem de programação e ferramentas disponíveis;
6. gerenciamento de configuração;
7. dados de teste e testes de regressão;
8. disponibilidade de pessoas com conhecimento no sistema.

O papel profissional da manutenibilidade9.11

O capítulo termina com uma provocação ética importante. Engenheiros de software têm responsabilidade profissional de produzir código que possa ser mantido e alterado, mesmo quando isso não aparece explicitamente como requisito do cliente.

Essa responsabilidade existe porque decisões internas de projeto afetam custos futuros, riscos operacionais e a capacidade da organização de responder a mudanças. Código difícil de manter pode funcionar hoje, mas criar uma dívida que outra equipe, outro orçamento ou os próprios usuários pagarão depois.

Questões9.12

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


def resumo_compra(valor):
    if valor >= 200:
        frete = 0
    else:
        frete = 15
    return f"Total: {valor + frete}"

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


def total_compra(valor):
    return valor + calcular_frete(valor)


def resumo_compra(valor):
    return f"Total: {valor + calcular_frete(valor)}"

Próximos passos9.13