📓 Anotações sobre clean code e clean architecture
Projeto para explorar os conceitos de refatoração, clean architecture e TDD
yarn installyarn buildPara iniciar o servidor:
yarn run devPara executar os testes, execute o comando abaixo com o servidor em execução:
yarn testPara inicializar o banco de dados:
docker-compose upPara para o docker:
docker-compose downPara parar processos antigos:
sudo lsof -i :3000kill -9 <PID>- Dividi as camadas de application, drive e resource em pastas separadas.
- Cada camada possui uma pasta de arquivos de teste, porém 2 testes de sucesso da camada de driver dependendem da camada de resource. Acho que isso não deveria acontecer, deveriamos mocar a camada de resource e ter um teste e2e ou integração com os dois.
- A camada de resource foi divida em um arquivo de configuração que trata da conexão e desconexão com o banco, outro arquivo para as queries e outro para validar e chamar a query de criação.
- A camada de driver foi divida em um arquivo de configuração que abre a conexão e desconexão com o servidor, lida com as portas, ouve o servidor, etc.
- A camada de aplication valida os parametros e chama o serviço de
/sign-upna camada de driver - As validaçoes em todas as camadas foram lidadas com
throw new Erroretry catch. - Removi os erros em números e os transformei e em mensagens descritivas para melhor entendimento do que aconteceu.
- Movi as regex para um arquivo separado dentro de seu contexto para melhorar a legibilidade do código.
- Adicionei uma validação na tabela do banco tornando emails unicos, visto que essa validação estava sendo feita apenas nas regras de negocio.
- É uma hipotese, mas acredito que não precisamos dos parametros
isPassengereisDriver, podemos ter um ou outro.
- Criar endpoint de GET para accounts p/ verificar se conta foi realmente criada, não confiar no resultado da response. O mesmo vale para a camada de resource
- Separar os testes por camadas. Ex: na camada de
application, não faz sentido termos testes que envolvem servidor, resposta, axios, etc. E elas não devem depender de outras camadas. Por exemplo, enquanto rodamos os testes de application, tanto faz se o driver ou resource estão rodando. - Implementacao de classes. Usamos a
interfacepara manter o contrato - O driver chama a camada de application e a camada de application chama a camada de resource.
- Usar a exeçoes do jest:
- "Pasta não é camada, é logica, podemos ter tudo no mesmo arquivo e mesmo assim ter a separação de camadas"