As “leis fundamentais” para escrever códigos na área de dados — parte I

Crédito: Crédito da foto: https://unsplash.com/photos/vc3iVL_znJ8?utm_source=unsplash&utm_medium=referral&utm_content=creditShareLink

O ano era 2021, eu acabava de entrar numa equipe em que todos eram da área de dados e minha primeira tarefa era adaptar um código em SQL que outra pessoa de outra área havia desenvolvido e incluir novas colunas para chegar em uma nova forma de cálculo de uma métrica.

Meu conhecimento em SQL naquele momento era básico, sabia o que um SELECT, WHERE e FROM faziam, mas isso é só a pontinha do que podemos fazer com essa linguagem, certo? Li e reli o código diversas vezes, jogando no google pra entender funções que eu não tinha visto até então, tirei dúvidas com n pessoas e no fim consegui fazer as alterações necessárias.

Dali em diante eu sempre me perguntava se existia alguma “fórmula mágica” para que pudesse escrever estes códigos pra que outra pessoa pudesse entendê-los mais facilmente, fazer alterações ou até utilizar como um estudo para e construir algo parecido para uma outra análise ou uma gerar uma tabela que abastecesse um dashboard. Claro que com o tempo vamos aprendendo na prática formas que não funcionam tão bem ou até formas mais efetivas e vou melhorando conforme vou aprendendo nesse processo.

Passeando pela minha estante de livros, encontrei o título “As Leis Fundamentais do Projeto de Software” do autor Max Kanat-Alexander que até então eu havia comprado mas não tinha encontrado ainda o momento correto… Veja bem: eu não construo softwares, eu não sou uma programadora mas utilizo por exemplo a linguagem sql para construir análises e me ajudar com tratamentos de tabelas que abastecem um dashboard.

Sem mais delongas, compartilho a primeira parte desse artigo com 5 lições importantes que aprendi com a leitura do livro aplicando ao mundo de analista de business intelligence ou analista de dados ou pra você que possui outro “título” e constrói códigos em geral pra construir suas análises:

1. Seus códigos devem ter como premissa ajudar alguém: seu código precisa ser algo útil que vai facilitar o dia a dia seu ou de outro cliente interno/externo.
2. Seus códigos devem ser escritos de forma fácil: quando criamos algo difícil fica difícil de alterarmos, fazermos manutenções e até mesmo repassar esse material pra outro colega trabalhar nele. Se seu código é fácil, seus colegas podem passar mais tempo pensando e desenvolvendo funcionalidades úteis para os usuários finais (e te contatando menos pra tirar dúvidas, né?)
3. Pensando no entendimento dos outros sobre algo que você desenvolveu: se certifique que há algum documento breve, ou o mais breve possível, que explique de forma macro seu código. Liste: qual é o objetivo? quais são as premissas de negócio? E, por que não adicionar um fluxo pra deixar o entendimento mais fácil?
4. Muito provavelmente seus códigos precisarão de manutenções: Quando alguém te pede uma mudança no código significa que as pessoas realmente estão usando seu código (e que bom né?!) e que novas premissas ou refinamento das premissas existentes foram discutidas e assim o resultado final pode ficar mais acurado ainda e objetivo de ser útil é reforçado! E se surgirem muitas solicitações de alterações priorize as que trazem maior valor e exigem menos esforço 😉
5. Toda manutenção de código possui um custo aparente e não aparente:

• Tempo e esforço da pesquisa e desenvolvimento da sua estratégia pra tornar aquela demanda de negócio em uma estrutura lógica (não aparente)
• Tempo pra conversar com seus outros colegas da área pra trocar figurinhas se a estratégia que você pensou faz sentido, se eles já fizeram algo parecido e você pode se basear (não aparente)
• Tempo que você de fato irá programar (aparente)
• Tempo e esforço pra pensar nos testes que você vai fazer pra garantir que a nova funcionalidade e/ou alteração está funcionando conforme esperado (não aparente)
• Tempo pra testar todo o código e garantir que o todo está funcionando (aparente e não aparente)

Antes de encerrar esse primeiro artigo, uma frase do autor que estou tentando levar pra todos meus produtos de dados:

“Um bom programador cria coisas que são fáceis de entender, para que seja realmente fácil eliminar todos os erros.”

Você já leu esse livro? O que achou desses pontos? E não menos importante: você gostaria de ver mais conteúdos como esse por aqui?

Até a próxima!