Probably Are Gonna Need It (PAGNI): 6 processos que você certamente precisará implementar em seu código
Quando falamos de desenvolvimento de software, seja lá onde você esteja, existem algumas coisas que inevitavelmente você vai precisar implementar, os famosos PAGNIs — Probably Are Gonna Need Its (dependendo das características do seu projeto).
Neste post, compartilho uma lista com 6 PAGNIs para você ficar de olho:
1. Testes automatizados
Acho que todos concordamos que testes garantem o comportamento das várias partes dos nossos projetos e que, quando bem escritos, podem atuar como forma de documentação e até mesmo guiar novas pessoas desenvolvedoras que entrem no time.
Sabendo disso, manter testes com uma boa cobertura e uma pipeline de execução automática sempre que algo novo é adicionado ao projeto, é imprescindível se você está desenvolvendo um software.
Dois conceitos sobre teste que eu gosto de utilizar e recomendo são o AAA (Arrange, Act, Assert)* e o FIRST (Fast, Isolated, Repeatable, Self-validating, Timely)*, que eu posso explorar mais em um próximo post.
2. Deployment Automatizado
Já trabalhei em diversos lugares que não tinham deployment automatizado e devo dizer… isso é uma porcaria! Deixar trabalhos repetitivos para pessoas fazerem é a receita para problema, afinal nós somos humanos e suscetíveis a falhas.
Além disso, um pipeline de deployment automatizado agiliza as entregas, torna o processo reproduzível e faz com que as pessoas possam focar nas próximas demandas, sem ter que se preocupar com a complexidade do deployment!
Isso pode ser feito com várias ferramentas e plataformas e hoje em dia. Uma boa alternativa é executar seus pipelines de deployment usando o GitHub Actions, que além de útil e gratuito, te dará uma ótima base para trabalhar com outras plataformas também.
3. Logs e Metricas
Pessoal, precisamos conversar…
Se estamos falando de projetos sérios, precisamos falar de logs e métricas de aplicações. São exatamente esses dados que vão nos trazer uma série de possibilidades quando estivermos precisando melhorar ou apenas corrigir nossa aplicação.
Trate bem seus logs, envie-os para plataformas fora da infra da sua aplicação (ou interna, porém dedicada), onde elas não esgotem espaço em disco e possam ser usadas para gerar visualizações, dashboards, alertas e etc…
Isso te dará uma nova perspectiva sobre quais problemas e features priorizar para entregar valor onde seus usuários mais precisam.
4. Ajustes finos em Database ou Queries
O pior problema quando estamos criando e mantendo uma aplicação do zero até a infraestrutura, é negligenciar configurações e utilizar os defaults das ferramentas que estamos usando. Isso com nossos bancos de dados não seria diferente.
Verifique sempre antes de colocar a suas aplicações em produção, coisas como: credências, acessos simultâneos, espaço em disco para as informações, configure rotinas de backup e alertas para te informar de possíveis problemas.
Para as queries eu nem preciso dizer para soltar a mão daquele seu ORM maroto e parar de acreditar em tudo que ele te diz né!? Precisamos ser muito críticos com as queries auto geradas de ORMs e Query Builders, e validarmos constantemente se estamos trabalhando os dados usando a melhor estratégia possível.
Sempre verifique as queries geradas e veja se, tanto a query quanto a performance, são as esperadas (e caso não sejam, faça tunings nas suas queries para elas trabalharem como esperado).
Sobre o banco, sempre verifique se as configurações estão dimensionadas corretamente para sua aplicação e infraestrutura.
5. Caching
Se existe uma certeza nessa vida é que você como pessoa desenvolvedora de software vai se deparar com um cache (ou a necessidade de criar um rsrs). Caches são peças-chave no design dos nossos projetos e nos ajudam escalar e usar nossos recursos de forma mais inteligente.
Uma boa camada de Caching, quando bem aplicada, inclusive pode trabalhar colaborativamente na redução de custos e trazendo uma sensação de “boa performance” ao sistema. Então, aprenda a lidar com caches e pare de dar desculpas furadas que isso é algo difícil.
Treine de forma consistente e aplique os conhecimentos que estiver aprendido em um ambiente controlado, meça os tradeoffs e aplique sempre que fizer sentido para resolver seu problema.
6. Entender e usar variáveis de ambiente para configurações
É muito importante que você entenda que uma das piores formas de ter um incidente de segurança é pegar uma chave “hard coded” (dispostas diretamente no seu código) em texto puro. Ainda mais se o seu projeto estiver público em uma plataforma como o GitHub. Já conseguiu visualizar o tamanho do problema? rsrs
Chaves de configurações utilizando variáveis de ambiente são especialmente eficientes. Não apenas para isso, mas também permitem que você possa trocar suas configurações sem sair correndo e buscando em toda a sua codebase por lugares onde você copiou e colou a chave.
(existem também outras vantagens, que eu posso abordar em um novo texto).
Sabendo disso…
Boas práticas e processos levam você a ter cada vez mais familiaridade em criar softwares maduros e que gerem valor para você ou seus usuários. Isso faz com que a melhoria e evolução constante seja possível e a gestão das demandas (features novas e bugs) possa ser feita de forma organizada e guiada por dados.
E se você tiver interesse em um trabalhar dentro de um time World Class com muita gente boa tocando engenharia de software de verdade, dê uma olhadinha em nossas vagas abertas e vem trabalhar com a gente :)
🙋 Alguns Termos Usados
AAA (Arrange, Act, Assert) é um conceito de estrutura dos casos de teste que explora a organização de cada caso como Organizar, Agir e Validar: https://www.lambda3.com.br/2010/08/testando-com-aaa-arrange-act-assert/
FIRST (Fast, Isolated, Repeatable, Self-validating, Timely) é um conceito que explora que seus testes devem ser: Rápidos, Isolados, Repetíveis, Autovalidante e “no momento certo”: https://agileinaflash.blogspot.com/2009/02/first.html
