Uma coisa que a gente sempre faz é falar "ah, to fazendo o caminho feliz agora", sendo caminho feliz quando o programa da sucesso, da tudo certo no que ele tinha que fazer, integração não da erro e tá todo mundo feliz. Mas, meus amigos, vejam, a vida não é assim.

Pra mim, uma das melhores habilidades de um desenvolvedor é a de se precaver a erros que são possíveis de acontecer. Quando a gente fala de uma api, falo da habilidade de normalizar os dados na entrada antes ir pra regra de negócio. Quando falo de integração, falo de tratar possíveis erros que possam acontecer, sendo específico nos erros que você consegue prever, e genérico em erros que você não tem total controle.

Cê já ouviu falar de Programação Defensiva? Se não, então deveria começar a pensar nessas coisas. Programação Defensiva são conceitos pra garantir a estabilidade do projeto em, digamos, tempos de crise. Sabe aquele dia que o ambiente inteiro caiu? Nada funciona? Sua empresa criou uma War Room pra tentar ver o que aconteceu? Bem, se você tiver usado conceitos da programação defensiva, seu serviço pode até não estar funcionando se ele depender de alguma integração, mas com certeza seu projeto não caiu de vez e o dono da empresa tá pedindo satisfação pra você do porque isso aconteceu.

Dicas pra programação defensiva? Bem aqui vão algumas:

• Imagina aqui uma api que você tem um controller e um service. O controller é quem recebe a requisição, e o service é a sua camada de negócio. Faça seu controller tratar os dados que você recebe antes de mandar pro service. Garanta que todos os dados obrigatórios estão preenchidos e se estão com o tipo certo - string, number, boolean, coisas assim-, e se não estiverem, retorne uma mensagem de erro amigável falando qual campo está faltando ou qual campo está com o formato errado.

• Quando cê faz integrações, garanta que você trate todos os possíveis erros da integração, imagináveis e inimagináveis. Caso essa integração não tenha documentado os erros, vai testando quais que são possíveis, e depois trata o resto de forma genérica.

• Conceitos de programação funcional ajudam muito a evitar erros bobos. Funções puras, não usar estado global e sempre trabalhar com variáveis imutáveis ajudam muito.

Nota: Eu não falei aqui sobre como tratar as regras de negócio porque a gente recebe do negócio o que que precisa estar certo. Eu entendo que programação defensiva está além das coisas explícitas que a gente recebe

Mas beleza, você se prepara e trata todos os erros, mas eai, o que cê faz depois? Cê precisa repassar esses erros. Se você é uma api, provavalmente cê tem que retornar esses erros pra alguém, e como cê faz isso? Erros descritivos devem ser tão bem pensados quanto o código de uma api. Quando fazemos uma api, essa api é para os outros também, não apenas pra gente - e mesmo se fosse só pra gente, acho que você não gostaria de pegar esse erro aqui:

Use mensagens de erro descritivas, e não só mensagens de erro, use também códigos de erro. Não, não códigos de http, como 404, 400 e coisas assim, até porque, vários erros podem resultar no mesmo código http. Use códigos como "USER_NOT_FOUND" ou "ITEM_NOT_IN_STOCK", dessa forma, se você tiver um fluxo muito grande com várias regras, pelo menos a pessoa que fizer integração com você vai poder saber o que que deu de errado.

Geralmente eu faço dessa forma:

{
    "description": "User not found",
    "code": "USER_NOT_FOUND"
}

Desse jeito tem uma mensagem descritiva pra uma pessoa ler, e o código que fica mais fácil programaticamente pra pessoa tratar os possíveis erros.

Acho que esse artigo aqui tem duas mensagens:

• Nós sempre temos que prezar pela qualidade do que fazemos, e dentro disso está embutido a resiliência das nossas aplicações. Se a gente pode evitar esses erros que com certeza, alguma hora vão quebrar as nossas aplicações, porque não fazer a aplicação já pensando nessas coisas?

• Não programamos apenas para nós. Tudo que a gente faz, provavelmente vai ter alguém usando daqui a algum tempo. A capacidade de oferecer algo que funciona, e que se não funcionar, a gente possa dizer porque não funcionou não é apenas bom, mas também é empático.

Mas eaí, gostou do artigo? Segue lá nas redes, se quiser, pode comentar até sobre o que você quer que eu fale depois

Twitter - twitter.com/dudousxd

Github - github.com/DavideCarvalho