Programação

Python para analytics: pandas sem armadilha

A banca não pede código na sabatina, mas pergunta o que você faria com um arquivo problemático. As respostas que impressionam falam de tipo, de nulo e de grão — os três lugares onde o número sai errado sem ninguém perceber. E a pergunta seguinte é sempre quando NÃO usar pandas.

Como cai: Você recebeu um CSV de 4 GB com colunas mal tipadas. O que faz antes de qualquer análise?

Erros comuns

• ×Deixar o pandas inferir tipo. Coluna de código com zero à esquerda vira número e perde o zero; data vira texto; identificador grande perde precisão. Tipagem explícita na leitura evita tudo isso.
• ×Preencher nulo com zero por reflexo. Zero é um valor: entra na soma e na média. Nulo é ausência. Trocar um pelo outro muda o indicador sem avisar.
• ×Juntar tabelas sem conferir o grão. Se a chave não é única do lado direito, a junção multiplica linhas e a soma passa a contar duas vezes. É o erro mais caro e o mais silencioso.
• ×Usar laço para percorrer linhas. Além de lento, costuma esconder a lógica; operação vetorizada ou groupby diz melhor o que está acontecendo.
• ×Carregar tudo na memória quando o banco poderia filtrar. Trazer 4 GB para agregar 200 linhas é desperdício: empurre filtro e agregação para onde o dado está.
• ×Esquecer o fuso horário. Data sem fuso vira comparação errada entre origens diferentes, e o relatório fecha o dia na hora errada.

Vocabulário

grão

— O que uma linha representa. "Uma linha por pedido" e "uma linha por item do pedido" são grãos diferentes.

Git e revisão de código para quem trabalha com dados

A ementa pede Git, mas a banca pergunta outra coisa: como o seu trabalho vira algo que outra pessoa consegue revisar, repetir e reverter. Quem responde citando comandos perde; quem descreve o fluxo, o que escreve no pedido de revisão e o que olha ao revisar SQL alheio mostra que trabalha em equipe.

Como cai: Como uma mudança sua numa transformação chega ao repositório e ao ambiente dos outros?

Erros comuns

• ×Commitar na branch principal direto. Perde revisão, perde o momento em que alguém poderia ter visto o erro, e dificulta reverter só aquela mudança.
• ×Escrever mensagem de commit que descreve o diff. 'Altera consulta' não diz nada; a mensagem existe para explicar a intenção e o porquê, que o diff não mostra.
• ×Abrir pedido de revisão gigante. Revisão de 800 linhas vira aprovação sem leitura; mudança pequena e frequente é revisada de verdade.
• ×Revisar SQL procurando erro de sintaxe. Isso o computador faz; o revisor humano existe para checar grão, regra de negócio e impacto em quem consome.
• ×Versionar credencial junto com o código. Repositório é histórico permanente; apagar em commit posterior não apaga do histórico.
• ×Tratar notebook como entregável versionado sem cuidado. Notebook guarda saída e ordem de execução, o que polui o diff e esconde estado; o que vai para o repositório precisa ser limpo ou convertido.

Testes e reprodutibilidade em projetos de dados

A pergunta chega assim: 'como você sabe que esse número está certo?'. Quem responde 'conferi' não convence. Quem separa teste de código de teste de dado, dá exemplos dos dois e explica como outra pessoa reproduz o mesmo resultado amanhã, mostra maturidade que a maioria dos candidatos não tem.

Como cai: Como você garante que o número que você entregou hoje pode ser reproduzido daqui a seis meses?

Erros comuns

• ×Testar só o código. A transformação pode estar correta e o número errado, porque o dado de entrada mudou. Teste de dado é metade da suíte.
• ×Escrever teste que repete a implementação. Se o teste calcula do mesmo jeito que o código, ele passa junto com o bug; teste bom afirma o resultado esperado, de fora.
• ×Achar que notebook que roda é reproduzível. Ele carrega estado de execuções anteriores e a ordem das células pode não ser a de cima para baixo; reiniciar e rodar do zero é o teste.
• ×Esquecer de fixar a versão das bibliotecas. Mesma análise, biblioteca diferente, resultado diferente, meses depois.
• ×Não registrar qual corte do dado foi usado. 'Rodei ontem' não reproduz nada; é preciso a data de corte ou a versão da tabela.
• ×Cobrar cobertura de teste como número. Cobertura alta com asserções fracas dá falsa segurança; o que importa é o caso de borda coberto.