86% dos data engineers consideram que seu código não respeita os padrões de software engineering, segundo a McKinsey (2025). Sem controle de versão, código escrito diretamente em produção, nenhum teste, documentação ausente, sem code review.
É como se desenvolvêssemos serviços web sem Git, sem CI/CD, sem testes. É impensável para código de aplicação, mas é a realidade para dados. No entanto, um dado falso em produção pode custar milhões — uma estratégia comercial equivocada baseada em um número errado.
Os dados são tão críticos quanto o código de aplicação, senão mais. As equipes de dados devem adotar o rigor da engenharia de software. É um imperativo de qualidade.
Disciplina 1: Git para tudo
Primeira disciplina: todo o código de dados deve ser versionado no Git. Sem exceções. Queries SQL, scripts Python, configurações dbt, testes, documentação — tudo.
Cada mudança cria um commit com mensagem explícita. O histórico completo se torna rastreável: quem mudou o quê, quando, por quê. Para os data warehouses, isso significa que os scripts de transformação não devem viver em interfaces gráficas de ferramentas (no-code BI), mas em arquivos de texto gerenciados no Git.
Snowflake, BigQuery, Redshift permitem versioná-los. Essa disciplina leva alguns dias para ser implementada, mas elimina as regressões silenciosas.
Boas práticas: main/prod em read-only, feature branches para cada mudança, squash & merge na main para um histórico legível.
Disciplina 2: Code review obrigatória
Nenhum código de dados deve ir para produção sem review por um par. É uma barreira simples, mas formidável.
A code review captura bugs lógicos, casos limítrofes não tratados, oportunidades de reusabilidade, inconsistências com os padrões. A McKinsey relata que equipes que praticam code review sistemática reduzem em 45% as anomalias em produção.
As code reviews não devem ser dogmáticas: o objetivo é o aprendizado mútuo e a melhoria do código. O ritmo é importante: um reviewer deve comentar em até 24h. Uma PR que fica parada por 2 semanas quebra a produtividade.
As boas ferramentas (GitHub, GitLab, Bitbucket) integram discussões, sugestões, aprovações.
Disciplina 3: Testes automatizados
O código de dados deve ter testes. Testes unitários nas transformações, testes de integração no pipeline completo, testes de qualidade de dados.
Um teste é uma asserção: "esta coluna nunca deve ser nula", "este número de linhas deve ser > 1000". Os testes em dbt são simples de escrever e se executam na CI automaticamente.
Os testes complexos são feitos com Great Expectations — asserções de schema, distribuição estatística, etc. Sem testes, você navega às cegas. Com testes, você detecta regressões imediatamente.
O custo de um dado falso em produção é estimado em 10x o custo da prevenção por teste. É uma questão de ROI puro.
Disciplina 4: Documentation-as-code
A documentação deve estar no código, gerada automaticamente, mantida viva. No dbt, são os arquivos YAML com descrições para cada tabela e coluna. Em SQL, são os comentários inline. Em Python, são as docstrings.
A documentação morta (Word, wiki) não existe: ela fica obsoleta assim que é redigida. A documentação viva (dbt docs, Sphinx) muda quando o código muda. Deve ser consultável facilmente: o dbt Cloud expõe os docs gerados com o lineage, os testes, as descrições.
É a rastreabilidade absoluta: de onde vem cada coluna, quais testes a validam, como ela é utilizada.
Disciplina 5: CI/CD nativo
Cada push dispara uma cadeia de execuções. Linting do código — sqlfluff, pylint. Testes unitários. Testes de qualidade. Construção do DAG. Deploy em staging. Testes de integração. Depois deploy em produção.
Se um teste falhar, o deploy para. É a barreira definitiva contra transformações ruins. O dbt Cloud integra isso nativamente. Para código Python customizado, GitHub Actions ou GitLab CI orquestram.
A segurança desse processo reduz em 50% o tempo de onboarding dos novos data engineers: eles herdam uma base de código saudável, testada, documentada. É um ganho de confiança e produtividade imediato.
Em produção
Na Bomzai, falamos em operar. Operar é ter confiança. E a confiança vem do rigor. Controle de versão, testes, code review, documentação, CI/CD — não é luxo, é o mínimo para produzir em produção.
As equipes que adotam essas disciplinas reduzem anomalias, aceleram o onboarding, liberam os data engineers da ansiedade da produção. É um investimento que se paga em semanas, não em anos.
Os dados merecem o mesmo respeito que o código de aplicação. Porque os dados são a matéria-prima da decisão. E decisões erradas custam caro.
