Jupyter Notebook: o ambiente que ensina a programar sem CLI, e o problema que cria depois
Jupyter foi meu primeiro ambiente de Python sério. Perfeito para explorar dados. Péssimo para me ensinar como código de produção funciona.
O notebook tinha 47 células. Algumas eu não lembrava mais o que faziam.
Tinha uma célula no meio com df2 = df.copy() sem comentário. Tinha outra com # não rodar essa em vermelho. O estado do kernel dependia de ter rodado as células na ordem certa — e essa ordem não estava documentada em lugar nenhum.
Quando tentei reproduzir minha própria análise duas semanas depois, levei três horas.
Jupyter Notebook é um ambiente brilhante para exploração. Você escreve código, vê o resultado imediatamente, ajusta, vê de novo. Para entender um dataset novo, prototipar uma análise, testar uma hipótese rápida — é exatamente a ferramenta certa.
O problema não é o Jupyter. É o que Jupyter não te ensina.
Estado global implícito. Em um notebook, variáveis definidas em qualquer célula ficam disponíveis para todas as outras. Você pode redefinir df na célula 12 e quebrar a célula 8 sem perceber. Não existe escopo. Não existe isolamento.
Ordem de execução arbitrária. Células podem ser executadas em qualquer ordem. O notebook que funciona hoje pode não funcionar amanhã se alguém rodar as células diferente. Isso não aparece como bug — aparece como mistério.
Sem funções por padrão. Notebooks encorajam código procedural: faça isso, depois aquilo, depois mais aquilo. Sem abstração, sem reutilização, sem teste.
O que tive que desaprender quando saí do notebook para código "real":
Funções existem para isolar comportamento, não só para reutilizar. Código testável é código em função. Notebook não tem teste — tem "rodei e pareceu certo."
Reprodutibilidade é design, não acidente. Se sua análise não pode ser reproduzida com git clone + python main.py, ela não está terminada. Notebook que depende de kernel state não é reproduzível.
Estado precisa ser explícito. Em produção, variáveis globais são um problema de design. O hábito de deixar tudo no escopo global do notebook cria instintos errados para quando você vai escrever sistema real.
Isso não é argumento contra Jupyter. É argumento contra usar Jupyter como único ambiente de aprendizado.
A sequência certa: Jupyter para explorar → script Python para formalizar → módulo para isolar → teste para garantir. Jupyter é o rascunho. O código de produção é a versão limpa.
O problema da maioria dos cursos de data science é que ensinam Jupyter como destino, não como ponto de partida. A pessoa aprende a fazer análise mas não aprende a escrever software. Quando tenta passar para código que vai para produção, esbarra em todos os hábitos que o notebook criou.
Hoje quando vejo alguém que veio de data science entrando em engenharia de software, sei exatamente qual é o gap mais comum. Não é Python — Python eles sabem. É o instinto de escrever código isolado, testável, com estado explícito.
O Jupyter foi ótimo para me ensinar análise. Me ensinou mal a escrever software. Os dois fatos coexistem.
Essa semana: pega o último notebook que você escreveu. Consegue transformar em script Python que qualquer pessoa pode rodar com python script.py sem instrução adicional?