Refatoração do ERP na Prática #13. O CRUD Passou, Mas o Código Ficou Feio | Build in Public, TDD

Nesta parte, fechamos o primeiro CRUD do novo ERP refatorado: implementamos GET por ID, DELETE e PUT, sempre usando os testes como guia para manter o contrato da API funcionando. O código passa nos testes, mas começa a mostrar seus problemas: controller com muita responsabilidade, conexão com banco repetida, detalhes do MySQL espalhados pela aplicação e conflito entre o modelo do banco (bancoID) e o contrato da API (id). Esse é exatamente o ponto da série: primeiro fazer funcionar, depois enxergar onde o acoplamento nasce e preparar o caminho para arquitetura hexagonal, ports and adapters e Clean Architecture. --------------------------------------------------------------------------------------------------------- Hub do Canal: https://refatorador.com Comunidade (apenas avisos, sem SPAM): https://refatorador.com/whatsapp Projeto no GitHub: https://github.com/drummerpva/erp 00:00 Indo para o próximo teste 00:15 Criando o GET com parâmetro 01:13 Buscando por chave primária 02:08 Mapeando o retorno da API 02:45 Teste do GET funcionando 03:18 Implementando o DELETE 04:33 Retornando 404 quando não encontrar 05:30 Fazendo o teste passar 05:48 Partindo para o PUT 06:11 Casos de erro, bugs e TDD 06:59 Recebendo os dados da atualização 08:10 A complexidade começando a aparecer 09:27 Salvando a alteração no banco 10:25 Explicando o fluxo do update 11:18 Aproveitando dados antigos quando faltar campo 12:44 Todos os testes passando 12:52 O código funciona, mas ficou ruim 13:25 O problema do bancoID vs id 14:02 Contexto do ERP gerado por código 15:02 Tudo dentro do controller Express 15:18 O risco de acoplar direto na biblioteca 15:50 Por que abstração e adaptadores ajudam 16:22 A proposta de conteúdo mais avançado 17:01 Encerramento #programação #refatoração #devbrasil