Preservar reparar refatorar ou reconstruir
Nesta aula
Escolher a intervenção pelo efeito desejado
Ao encontrar um sistema existente, o programador pode sentir vontade de recomeçar para entender tudo. A familiaridade com a própria solução é atraente, mas não elimina o conhecimento acumulado no sistema recebido. A escolha da intervenção precisa comparar comportamento, risco, custo e possibilidade de recuperar a situação anterior.
Preservar é manter algo que continua adequado. Reparar corrige um defeito. Refatorar altera a estrutura interna conservando o comportamento pretendido. Migrar transfere uma responsabilidade para outro ambiente ou solução. Reconstruir substitui uma parte ou o conjunto. Essas ações podem coexistir: preservar dados, reparar seleção e refatorar a organização do código não exige escolher um único rótulo para toda a aplicação.
Refatoração não significa apenas melhorar o código. Se a mudança passa a ocultar registros antes visíveis, existe uma mudança de comportamento e ela precisa ser reconhecida. Isso não a torna inadequada; torna inadequado apresentá-la como alteração estrutural neutra.
O defeito do catálogo e as alternativas
No cenário de estudo, a interface é legível e os registros têm formato válido, mas a resposta pública inclui serviços inativos. O objetivo é cumprir REQ-002. Antes de alterar, fornecemos uma entrada mista e observamos a exposição indevida. Essa observação caracteriza o defeito atual; não o transforma em comportamento que deva ser preservado.
| Alternativa | Benefício | Custo ou risco | Decisão do exemplo |
|---|---|---|---|
| Preservar tudo | Nenhuma mudança imediata. | Mantém o descumprimento de REQ-002. | Rejeitada para a seleção. |
| Reparar a seleção pública | Ataca diretamente o defeito. | Exige verificar consumidores e entrada inválida. | Escolhida para esta unidade. |
| Refatorar toda a interface | Pode melhorar organização. | Não é necessária para corrigir a exposição. | Adiada até existir motivo próprio. |
| Reconstruir com outra tecnologia | Permite nova estrutura. | Amplia superfície de mudança e revalidação. | Sem justificativa neste cenário. |
Registro de decisão preenchido
ADR significa registro de decisão arquitetural. É um texto curto que conserva contexto, escolha, alternativas e consequências. A orientação da AWS sobre ADRs é referência para esse tipo de registro; a escolha concreta abaixo pertence ao cenário didático da oficina.
| Campo do ADR-001 | Preenchimento |
|---|---|
| Título | Reparar a seleção pública sem reconstruir a interface. |
| Estado | Decisão adotada no cenário de estudo. |
| Contexto | REQ-002 é descumprido; dados válidos e apresentação podem ser preservados. |
| Decisão | Ajustar o módulo de catálogo para retornar somente os campos públicos dos ativos. |
| Alternativas consideradas | Manter defeito, refatorar interface inteira ou reconstruir. |
| Consequências | Rever seleção, consulta por identificador e integração HTTP; conservar dados de origem. |
| Autoridade | Papel de produto aceita o recorte; desenvolvimento responde pela solução técnica dentro dele. |
| Recuperação | Preservar a revisão anterior e retornar a ela se houver regressão; a versão anterior defeituosa não fica automaticamente liberada para exposição. |
| Reavaliação | Reabrir se o contrato de dados ou a finalidade pública mudar. |
O ADR não comprova que o reparo foi executado. Ele conserva a razão da escolha. Testes e observações posteriores devem demonstrar o resultado. Essa separação impede que a elegância da justificativa ocupe o lugar da verificação.
Procedimento de intervenção
- Reproduza o defeito com uma entrada pequena e registre o resultado indevido.
- Identifique o comportamento que deve permanecer e a regra que precisa mudar.
- Compare intervenções pelo alcance necessário, não pela preferência pessoal de tecnologia.
- Registre a decisão e preserve uma forma adequada de recuperar a cópia de trabalho.
- Execute verificações que demonstrem tanto a correção quanto a preservação dos comportamentos relacionados.
- Investigue divergências antes de ampliar a mudança para outros módulos.
Erros de escolha e condição de avanço
| Erro | Consequência | Reparo |
|---|---|---|
| Apagar serviços inativos do arquivo | Destrói informação para simular uma seleção correta. | Conservar a fonte e corrigir a saída pública. |
| Congelar o defeito em teste de caracterização | A suíte passa a exigir o erro. | Distinguir descrição do estado antigo de aceite da regra correta. |
| Reescrever para facilitar um ajuste pequeno | Introduz mudanças sem relação com a necessidade. | Limitar a intervenção e justificar separadamente nova arquitetura. |
A intervenção pode começar quando alvo, alternativa escolhida, evidência de preservação e recuperação estão claros. A unidade só termina quando a seleção e seus consumidores atendem ao aceite. Voltar ao estado anterior é uma ação de recuperação; se aquele estado contém um defeito impeditivo, a exposição da capacidade precisa continuar bloqueada.
Exercício resolvido
Um módulo tem nomes confusos, mas todos os aceites atuais estão demonstrados. Outro módulo envia um serviço inativo na resposta pública. Há tempo para uma única intervenção. Qual tratar primeiro e qual rótulo usar?
Ver solução comentada
Solução: o descumprimento de REQ-002 pede reparo prioritário. Renomear e reorganizar o módulo correto pode ser uma refatoração posterior, desde que conserve o comportamento. A resposta deve explicar que a prioridade vem do requisito descumprido e do impacto, não de um veto geral à refatoração. Se surgisse risco relevante no módulo aparentemente correto, a decisão teria de considerar essa nova evidência.
Referências para aprofundamento
Fontes para aprofundar: S08, orientação de ADRs, para conservar contexto, decisão e consequências; S17, definição de refatoração em refactoring.com, para distinguir reorganização interna de mudança de comportamento observável.
Fontes relacionadas
Consulte os limites e as seções de apoio de cada referência.
S08 S17Tente o exercício antes de consultar a solução. Marque a aula para organizar sua leitura.
A conclusão desta leitura não equivale a certificação ou aceite de um projeto real. Teste os exemplos no escopo indicado e registre as limitações.