Consolide código duplicado preservando as regras de negócio

Dois métodos semelhantes não são necessariamente uma única regra. Os processadores de pedidos e devoluções compartilham mecanismos de validação, mas usam prefixos, limites de frete e sentidos de movimentação de estoque diferentes. Remover essas diferenças seria uma mudança de comportamento.

Resumo do laboratório

[!NOTE] Código semelhante não significa a mesma política de envio ou inventário.

Conceitos · Primeira tarefa · Lista de evidências · Redefinir

Objetivos de aprendizagem

• Identifique duplicação exata versus semântica usando código real.
• Capture as saídas e os efeitos colaterais atuais antes da extração.
• Escolha uma pequena abstração compartilhada sem generalizar demais a política.
• Detecte uma refatoração que altera acidentalmente um limite.

Antes de começar

Prepare 07-duplication com a configuração comum. A fonte é a fixture ECommerceOrderAndReturn incluída. Use o SDK .NET de destino dela e um único processo de compilação.

Conceitos e casos de uso

Os processadores capturam e registram exceções. Portanto, um código de saída zero na demonstração não comprova que uma exceção esperada foi lançada. Este é um exercício de caracterização, não uma comprovação de segurança em produção.

Cenário do exercício

Você precisa reduzir a duplicação de manutenção sem alterar totais, estoque, mensagens de validação ou ordem dos eventos. Uma alteração de negócio separada precisaria de critérios de aceitação e revisão próprios.

Tarefa 1 - Capture uma linha de base real

1. Leia OrderProcessor.cs, ReturnProcessor.cs, Configuration/AppConfig.cs e os serviços que eles chamam.

2. Compile o projeto copiado:

   dotnet build ECommerceOrderAndReturn.csproj -m:1 -p:UseSharedCompilation=false
   dotnet run --no-build --project ECommerceOrderAndReturn.csproj
   

3. Registre os totais atuais de frete de pedidos/devoluções, o estoque antes/depois e os IDs rejeitados. Trate EXPECTED_OUTPUT.md como uma ilustração histórica, não como a saída de hoje.

4. Identifique timestamps ou identificadores gerados antes de comparar logs. Não remova valores de negócio apenas para fazer um diff parecer igual.

Tarefa 2 - Analise a duplicação com Ask

Compare OrderProcessor.Validate and ReturnProcessor.Validate. Cite the shared
mechanics and the policy differences. Do the same for shipping and inventory.
Do not edit. Flag swallowed exceptions separately from the refactoring scope.

Confira a resposta com estas regras concretas de frete:

Não substitua “acima de” por “pelo menos”. Teste valores imediatamente abaixo, iguais e acima dos limites antes de mover código.

Tarefa 3 - Planeje uma extração

1. Em Plan, escolha validação ou frete para a primeira alteração.
2. Exija uma tabela com regras preservadas, parâmetros propostos, chamadores existentes, casos de regressão e reversão.
3. Explique por que uma função auxiliar compartilhada é mais simples que uma nova hierarquia de classes.
4. Mantenha os métodos públicos originais de processamento e a ordem dos efeitos colaterais.
5. Defina um ponto de parada após uma extração que preserve o comportamento.

Tarefa 4 - Implemente e questione o resultado

1. Peça a Agent que implemente somente essa extração.
2. Inspecione todos os chamadores; funções auxiliares não usadas não constituem consolidação.
3. Adicione asserções sobre valores determinísticos ou um harness de caracterização de escopo restrito. Não renomeie uma transcrição do console como “testes unitários”.
4. Execute novamente a mesma compilação/demonstração e as asserções adicionadas.
5. Inverta temporariamente um limite na cópia descartável. Confirme que a asserção relevante falha e restaure-o.
6. Considere uma segunda extração somente depois que a primeira estiver verificada.

Verifique seu trabalho

• Os pontos de entrada públicos e as regras observáveis permanecem inalterados.
• Os limites de igualdade de peso/valor são testados.
• Reservar e restaurar continuam tendo efeitos opostos no estoque.
• As novas asserções rejeitam um limite intencionalmente incorreto.
• O diff contém reutilização real, não uma abstração sem uso.

Solução de problemas

Prática independente

Refatore uma função auxiliar de notificação preservando os métodos públicos e as mensagens. Explique por que alterar o comportamento de novas tentativas seria uma funcionalidade separada.

Restauração

Pare a demonstração, salve a linha de base e as evidências da comparação e restaure somente os arquivos nomeados do exercício na cópia descartável. Não sobrescreva a fixture de origem.

Referências oficiais

• Planejar com agentes
• Boas práticas para agentes
• Suporte a testes C#