Retorno controlado
Nesta aula
Corrigir sem apagar a história
Retornar significa revisar uma decisão ou artefato porque surgiu informação que altera sua validade. Não é recomeçar por insegurança nem desfazer tudo por conveniência. O retorno controlado registra gatilho, impacto, evidências invalidadas, correção e nova verificação. Ele conserva o que ainda é sustentado e torna visível o que deixou de ser.
Na Oficina Caracol, imagine que uma edição de dados troque ativo: true por ativo: "sim" em um registro. A estrutura exige um booleano, que só admite true ou false. O dado agora viola o contrato. A implementação correta deve sinalizar a entrada inválida; isso não significa que o catálogo voltou a listar serviços válidos. É necessário corrigir o dado para recuperar essa capacidade e verificar o percurso.
Essa diferença evita um erro comum: alterar o validador para aceitar qualquer entrada apenas para deixar o teste verde. Se o contrato é adequado, consertamos o dado. Se o contrato realmente precisa mudar, registramos a decisão e analisamos todos os consumidores. O motivo da alteração determina a correção, e a evidência determina o estado que podemos declarar.
Registro de retorno preenchido
| Campo | Preenchimento do cenário |
|---|---|
| Gatilho R-CAT-03 | Campo ativo editado como texto em pratica/data/casos.json |
| Contrato vigente | ativo obrigatório e booleano; dados públicos sem campos internos |
| Dependentes diretos | Validação de dados e carregamento da listagem |
| Dependentes do fluxo | Resposta do servidor e estado de erro apresentado na página |
| Evidências afetadas | Verificações que usaram o arquivo anterior para afirmar listagem válida |
| Preservado com motivo | Estilos sem relação com o tipo do campo; contrato mantido |
| Correção escolhida | Restaurar booleano correto nos dados; não flexibilizar a validação |
| Encerramento previsto | Validar dados, repetir testes e confirmar listagem integrada na versão corrigida |
A análise não exige modificar todos os dependentes. Ela exige verificar se foram afetados. Um teste isolado do módulo com a mesma entrada válida pode continuar relevante para aquele caso, enquanto a prova integrada que usou o arquivo antigo não sustenta a nova versão dos dados. A condição de erro também deve ser inspecionada para impedir que o usuário receba silêncio ou uma página aparentemente vazia.
Ampliar diagrama Procedimento e estados
- Registre o fato observável, a versão afetada e o requisito que deixou de estar sustentado.
- Mapeie consumidores diretos e indiretos. Separe artefato a mudar de artefato apenas a verificar.
- Reclassifique os itens afetados conforme a evidência que resta. Não aplique um rebaixamento idêntico sem justificativa.
- Faça a menor correção suficiente, preservando o contrato ou revisando-o explicitamente.
- Execute as verificações locais e integradas pertinentes; emita novo gate ligado ao registro de retorno.
Se a versão atual do item já não atende ao contrato estruturado, M3 pode ser o estado sustentado antes de corrigir a implementação ou o dado. Quando a correção existe, mas falta verificá-la, M4 é mais preciso. A promoção a M5 exige aprovação das verificações aplicáveis; M6 requer a integração comprovada. O mero tempo decorrido não causa regressão sem uma política que explique a expiração.
Erros e reparos correspondentes
| Erro | Reparo |
|---|---|
| Manter o gate antigo após mudança relevante | Marcar seu alcance e reavaliar a versão atual antes de reutilizá-lo |
| Corrigir dados sem conferir consumidores | Repetir o percurso que depende do dado, além da validação local |
| Mudar o contrato só para aceitar o erro | Restaurar o dado ou justificar formalmente uma nova regra |
| Reabrir arquivos independentes | Exigir uma relação de impacto antes de incluir cada item no retorno |
Exercício e solução comentada
Dados: um caso ativo muda somente sua descrição, mantendo id, titulo e ativo. O contrato de descrição não muda. A versão anterior foi verificada; a nova ainda não. Informe o que deve ser alterado, o que deve ser conferido e o que pode ser preservado.
Ver solução comentada
Solução: alterar o registro no arquivo de dados e conferir se a descrição respeita o contrato, é entregue na representação pública e aparece corretamente na página. Repetir as verificações pertinentes ao percurso; a regra de seleção de ativos não precisa ser reescrita. Seu código pode ser preservado, enquanto a evidência do conjunto de dados anterior deve ter seu alcance reconhecido. Examinar se a mudança textual afeta leitura ou apresentação antes de dispensar a inspeção.
- Rubrica: distinguir mudança de dados e mudança de regra; incluir a apresentação entre os dependentes; preservar código com justificativa; exigir evidência atual do comportamento afetado.
- Gate: o retorno só encerra quando causa, impacto, correção e revalidação estão ligados à mesma versão e nenhuma falha impeditiva permanece escondida.
Leitura relacionada
S07, seção sobre desfazer alterações, descreve mecanismos de histórico; S16, atividades de teste e testes relacionados a mudanças, ajuda a escolher confirmação e regressão. Um comando de reversão não substitui a análise do impacto.
Fontes relacionadas
Consulte os limites e as seções de apoio de cada referência.
S07 S16 S03Tente 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.