O que os tutoriais não te contam sobre criar um produto real (e sozinho).
Alguns pontos que devem ter atenção no processo de desenvolvimento de um produto.
Nos últimos 6 meses, eu passei por um desafio brutal: estou desenvolvendo um grande produto do zero, totalmente sozinho, lá na empresa onde trabalho.
Durante esse tempo, a quantidade de coisa que precisei pesquisar não tá escrito. Tive que mergulhar de cabeça em tudo que envolve o fluxo de vida de uma aplicação séria que vai para produção: desde arquitetura e modelagem de dados até regras de segurança, regras de negócio, front-end, back-end… enfim, tudo aquilo que você precisa dar uma atenção real para o sistema não cair.
Só que, no meio desse processo, comecei a perceber algumas nuances. Detalhes que ninguém fala em vídeo do YouTube ou em artigo de internet. É muito fácil você achar um tutorial ensinando como implementar registro e login com JWT, mas essas coisas abaixo, ninguém solta com tanta facilidade.
Histórico de Ação (Logs de Auditoria)
Admita: quando você senta para desenhar uma aplicação, o histórico de ações nunca é uma das primeiras funcionalidades que passa pela sua cabeça. E, para ser sincero, talvez você nem chegue a pensar nisso se o pessoal da auditoria não mencionar.
Mas vá por mim, escuta o que estou te dizendo:
Você vai querer ter um histórico de auditoria bem amarrado, sabendo exatamente quem editou o quê, para o quê, e o que aconteceu em cada etapa do seu processo principalmente se for algo relevante e que custe dinheiro para a sua empresa.
Em algum momento vai dar algum problema, os questionamentos vão surgir e, se você não tiver isso fortemente implementado, vai passar um estresse que não compensa…. comprovar, justificar ou contrariar a verdadeira história dos acontecimentos. Não espere a bomba estourar para ver que precisava disso.
Termos de Uso de Dados
Para quem nunca lidou com isso de perto, parece a coisa mais simples do mundo: ah, é só colocar um campo booleano lá no banco e pronto.
Só que a história muda totalmente de figura quando o cliente resolve revogar os termos. É aí que o bicho pega, porque você precisa garantir que os processos passados não sejam afetados e, do nada, fiquem inconsistentes porque o presente mexeu no que já passou. A lógica de solução aqui tem que seguir a mesmíssima linha do histórico de ações: imutabilidade e rastro.
Mensagens claras poupam tempo (principalmente o seu)
Implementar mensagens de erro claras e que façam sentido é uma parada que, na maioria das vezes, exige um esforço muito baixo de código. Em compensação, o retorno em economia de tempo é gigantesco.
Ninguém merece ter que ficar adivinhando o que raios aconteceu com o usuário. Talvez você nem seja a pessoa responsável por atender o cliente final na ponta, mas seja consciente. Facilite o trabalho de quem tá na sua equipe ou nos times parceiros. Além de ser uma boa prática, evita que um problema simples vire um chamado que vai acabar caindo de volta no seu colo para você descobrir o que houve.