Refatore uma função grande sem perder os caminhos de erro

Um método mais curto não é automaticamente mais seguro. Extrair uma etapa de pagamento pode mover a liberação do estoque para fora do caminho de falha. Suas evidências devem cobrir falhas e efeitos colaterais, não apenas o pedido bem-sucedido.

Resumo do laboratório

[!NOTE] Uma rejeição de pagamento não deve deixar o inventário reservado incorretamente.

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

Objetivos de aprendizagem

• Mapeie um método longo em responsabilidades e transições de estado.
• Preserve ordem, mensagens de erro e compensação durante a extração.
• Prefira uma extração executável a uma coleção de implementações vazias sem uso.
• Revise o comportamento antes/depois independentemente da explicação do agente.

Antes de começar

Prepare 08-functions usando o guia de ambiente. Use a fixture ECommerceOrderProcessing incluída. Todos os pagamentos, endereços e notificações são sintéticos.

Conceitos e casos de uso

Cenário do exercício

OrderProcessor.ProcessOrder coordena validação, estoque, pagamento, frete, notificações e saída de auditoria. Mantenha o comportamento existente, tornando cada etapa mais fácil de inspecionar.

Tarefa 1 - Rastreie o método existente

1. Leia src/ECommerce.ApplicationCore/Services/OrderProcessor.cs, suas interfaces e as implementações em src/ECommerce.Infrastructure/Services.

2. Em Ask:

   Trace ProcessOrder from input validation to completion. For each exit path,
   list changed state, audit events, inventory release, and the returned result.
   Cite the implementation rather than assuming the interface guarantees it.
   

3. Anote a sequência conceitual a seguir com base no código-fonte real.

---
config:
  theme: base
  look: classic
  themeVariables:
    darkMode: false
    background: "#ffffff"
    primaryColor: "#f5f5f5"
    primaryTextColor: "#111111"
    primaryBorderColor: "#555555"
    secondaryColor: "#e0e0e0"
    secondaryTextColor: "#111111"
    secondaryBorderColor: "#666666"
    tertiaryColor: "#bdbdbd"
    tertiaryTextColor: "#111111"
    tertiaryBorderColor: "#444444"
    lineColor: "#444444"
    textColor: "#111111"
    mainBkg: "#f5f5f5"
    nodeBorder: "#555555"
    clusterBkg: "#ffffff"
    clusterBorder: "#999999"
    edgeLabelBackground: "#ffffff"
    actorBkg: "#e0e0e0"
    actorBorder: "#555555"
    actorTextColor: "#111111"
    actorLineColor: "#777777"
    signalColor: "#333333"
    signalTextColor: "#111111"
    labelBoxBkgColor: "#f5f5f5"
    labelBoxBorderColor: "#777777"
    labelTextColor: "#111111"
    loopTextColor: "#111111"
    activationBkgColor: "#bdbdbd"
    activationBorderColor: "#555555"
    noteBkgColor: "#f5f5f5"
    noteTextColor: "#111111"
    noteBorderColor: "#777777"
    attributeBackgroundColorOdd: "#f5f5f5"
    attributeBackgroundColorEven: "#e0e0e0"
---
sequenceDiagram
    accTitle: Limite de compensação do processamento de pedidos
    accDescr: Uma reserva precede o pagamento; um pagamento rejeitado deve liberar a reserva antes que um resultado de falha seja retornado.
    participant Caller as Chamador
    participant Processor as Processador
    participant Inventory as Estoque
    participant Payment as Pagamento
    Caller->>Processor: ProcessOrder
    Processor->>Inventory: Reservar estoque
    Inventory-->>Processor: Resultado da reserva
    Processor->>Payment: Tentar pagamento
    alt Pagamento aceito
        Payment-->>Processor: Aceito
        Processor-->>Caller: Continuar o fluxo documentado
    else Pagamento rejeitado
        Payment-->>Processor: Rejeitado
        Processor->>Inventory: Liberar reserva
        Processor-->>Caller: Resultado de falha e evidências de auditoria
    end

Legenda. Os cabeçalhos dos participantes identificam os colaboradores. As setas contínuas são chamadas; as tracejadas são respostas. Os ramos alt diferenciam sucesso de rejeição.

Explicação. Este diagrama enfatiza a obrigação de compensação. Complete-o com os ramos de frete e notificação da fixture antes de tratá-lo como um modelo completo; ele não é um rastreamento de um serviço de pagamento realmente contatado.

Tarefa 2 - Estabeleça evidências dos ramos

1. Compile somente o projeto de console:

   dotnet build src/ECommerce.Console/ECommerce.Console.csproj -m:1 -p:UseSharedCompilation=false
   dotnet run --no-build --project src/ECommerce.Console/ECommerce.Console.csproj
   

2. Registre os resultados de pedido válido, e-mail inválido, pagamento recusado e pedido suspeito.

3. Inspecione o arquivo de auditoria gerado no diretório de trabalho do processo.

4. Diferencie campos de negócio de timestamps. Timestamps de transcrições antigas e datas de validade de cartões de exemplo não devem ser usados como resultados esperados atuais.

5. Adicione uma asserção sobre a liberação da reserva em um pagamento recusado. Se a demonstração existente apenas imprimir resultados, um código de saída zero é evidência insuficiente.

Tarefa 3 - Projete uma extração delimitada

Use Plan:

Extract only payment processing and its documented compensation boundary.
Preserve public signatures, result semantics, audit order, and inventory release.
List tests for acceptance, rejection, and failure before reservation.
Do not add retry, concurrency, or exception-swallowing fallbacks.

Revise onde permanece a responsabilidade pela limpeza. Rejeite uma extração que faça tanto o chamador quanto a função auxiliar liberarem a mesma reserva.

Tarefa 4 - Implemente um recorte

1. Peça a Agent que faça a extração planejada e atualize os chamadores.
2. Inspecione todo o diff, especialmente retornos antecipados e blocos finally.
3. Execute as mesmas verificações e sua asserção de compensação.
4. Omita temporariamente a chamada de liberação. Confirme que a asserção falha e restaure-a.
5. Só então considere a extração de validação ou frete como outro recorte.

Verifique seu trabalho

• Os cenários existentes preservam a semântica dos resultados.
• A rejeição de um pagamento libera a reserva exatamente como antes.
• Uma falha anterior à reserva não realiza compensação inadequada.
• A ordem dos eventos de auditoria está explicada e verificada.
• Uma mutação negativa é detectada.

Solução de problemas

Se as exceções desaparecerem, compare os limites de erro em vez de adicionar uma captura genérica. Se o estoque diferir, verifique a liberação duplicada e a mudança na ordem das chamadas. Se o método ficar mais curto, mas as responsabilidades continuarem acopladas por muitos parâmetros de saída, revise a abstração em vez de contar linhas.

Prática independente

Aplique a abordagem ao ServerLogAnalysisUtility incluído em uma cópia separada. Especifique a codificação dos arquivos, o comportamento para linhas malformadas e a ordenação da saída antes da extração.

Restauração

Pare o processo do console, salve as evidências e restaure somente os arquivos-fonte e de testes nomeados na cópia descartável. Remova somente o arquivo de auditoria gerado nessa cópia.

Referências oficiais

• Planejamento
• Testes C#
• Boas práticas de exceções