Em pesquisa acadêmica, a programação já não pertence a uma área do conhecimento. De economistas modelando agentes heterogêneos a historiadores analisando arquivos digitais, o código computacional tornou-se uma linguagem franca da descoberta. Para a vasta maioria, o objetivo não é se tornar um engenheiro de software, mas sim usar a computação para responder a perguntas científicas.
O desafio, portanto, não é técnico, mas cultural. Exige que o pesquisador veja o código não como um rascunho descartável, mas como um ativo de pesquisa primário, tão duradouro e auditável quanto uma amostra de laboratório ou um dado de campo. Adotar ferramentas de controle de versão como o Git não é aprender a programar melhor; é praticar ciência de forma mais rigorosa.
“Qualquer tolo pode escrever código que um computador entende. Bons programadores escrevem código que humanos entendem.” — Martin Fowler (tradução livre)
Se a pasta do seu projeto contém arquivos como analise_final.py, analise_final_revisada.py e o desesperado analise_final_agora_vai.py, você não está sozinho. Se a sua colaboração se parece com uma troca de e-mails com anexos codigo_v2_comentarios_joao.zip, saiba que essa é a norma em muitos departamentos. Mas essa prática, embora comum, representa um dos maiores e mais silenciosos riscos à integridade do trabalho científico moderno.
Reprodutibilidade em computação científica
Enquanto você lê este artigo, economistas escrevem programas para simular o comportamento dos mercados; químicos e farmacêuticos escrevem código que prevê a eficácia de fármacos que ainda nem existem; biólogos ou cientistas sociais analisam grandes volumes de dados para encontrar padrões ocultos nos seus respectivos objetos de estudo…
Mesmo áreas tradicionalmente distantes da computação incorporam cada vez mais ferramentas computacionais em suas metodologias centrais. Para muitos pesquisadores nessas áreas, a programação não é vocação ou interesse principal, mas sim ferramenta necessária para responder às questões científicas que os motivam.
Exemplo: O que pode dar errado?
Aprecie a seguir a história da doutoranda Ana Ribeiro, que facilmente suscitará identificação no leitor.
Após incansáveis anos de trabalho, a pesquisadora Ana Ribeiro, doutoranda em neurociência computacional, finalmente submeteu um artigo promissor com seu modelo de rede neural para simular a tomada de decisão. Enquanto aguardava a resposta dos revisores, seu orientador, empolgado com os resultados, propôs duas novas e ousadas hipóteses para expandir o trabalho: uma envolvendo um mecanismo de "atenção seletiva" e outra, uma forma de "plasticidade sináptica" mais complexa.
Empolgada, Ana mergulhou de cabeça no desenvolvimento. A pasta do projeto logo se tornou um labirinto de arquivos como modelo_v2_atencao.py e modelo_v3_plasticidade_teste.py, com funções sendo reescritas e parâmetros sendo ajustados constantemente em múltiplas versões divergentes, sem um registro claro do que pertencia a qual experimento. Felizmente, as duas hipóteses forneceram resultados promissores que certamente integrariam sua tese.
Três meses depois, enquanto já preparava outro artigo com seus novos resultados, o e-mail que ela tanto esperava chegou. Eram boas notícias: o artigo anterior fora aceito com revisões menores. No entanto, uma das solicitações era aparentemente simples: "Poderia a autora rodar novamente a simulação da Figura 3, mas alterando um parâmetro de entrada, para validar a robustez do resultado?".
O que deveria ser uma tarefa de minutos se transformou em pânico! O código exato que gerou aquela figura não existia mais em sua forma original; ele havia sido canibalizado e modificado para os novos experimentos. Diante da confusão de arquivos, ela não conseguia garantir qual versão era a correta, tornando impossível atender ao pedido do revisor com integridade científica e colocando em risco a publicação de todo o seu trabalho.
A história de Ana é uma ficção, mas a tragédia vivida por ela se situa nas proximidades da dura realidade de inúmeros pós-graduandos e pesquisadores — mais do que gostaríamos de admitir.
Se Ana tivesse usado Git, a versão submetida estaria marcada por uma tag ou seria facilmente recuperável pelo commit relacionado, criando um registro permanente e imutável. As novas e empolgantes hipóteses seriam exploradas em ramificações paralelas (branches), sem jamais tocar na versão "oficial" do artigo. O pedido do revisor seria atendido com a confiança e o rigor que a ciência exige, em vez de se tornar uma crise que ameaçava meses de trabalho.
O código é a metodologia
O código que produz um resultado científico não é mero subproduto da pesquisa; constitui a especificação exata e inequívoca de como os dados foram transformados em conclusões, carregando, em si próprio, a reprodutibilidade do trabalho. O código se torna a própria metodologia.
Nenhum pesquisador sério publicaria resultados experimentais sem documentar meticulosamente os procedimentos utilizados. Cadernos de laboratório registram todos os detalhes técnicos e observações relevantes para o trabalho. Essa documentação permite que o pesquisador original reconstrua o que foi feito meses ou anos depois, e permite que outros pesquisadores tentem replicar os resultados independentemente.
A lógica subjacente é tão fundamental à prática científica que raramente é questionada. Registrar todas as alterações do código-fonte ao longo de um projeto de pesquisa, documentar qual versão foi utilizada para gerar cada resultado, e manter histórico completo do desenvolvimento computacional são práticas de mesma natureza e mesma importância.
A reprodutibilidade não é um detalhe técnico ou uma virtude periférica — é a linha que distingue a ciência da opinião. Se um pesquisador não consegue recuperar a versão precisa do código que gerou os resultados de um artigo, esses resultados, estritamente falando, não são mais reprodutíveis. Um trabalho que não pode ser verificado por terceiros não pode servir como uma fundação confiável para a construção de novo conhecimento.
Modificar código sem documentar a mudança é equivalente a alterar um procedimento experimental sem registrar a alteração. Usar uma versão diferente do código sem a identificar claramente é equivalente a trocar um reagente químico sem anotá-lo. Perder o histórico de desenvolvimento do código é equivalente a rasgar páginas do caderno de laboratório.
💡
Embora as conclusões de um trabalho constituam seu valor epistemológico central, a reprodutibilidade é a condição que as precede e as fundamenta. Numa ciência coletiva e internacional, um trabalho não deve ser reprodutível apenas para confirmar a conclusão do autor, mas para possibilitar à comunidade científica a obtenção de novas conclusões.
A solução pragmática
Para a implementação do versionamento de código, serão mínimas as mudanças na sua rotina — mas elas te forçarão a trabalhar de forma organizada. Utilizaremos duas ferramentas, gratuitas e complementares, que são o padrão absoluto no mundo hoje. Tratam-se do Git e do GitHub.
O Git é um sistema de controle de versões (VCS) distribuído, ou seja, a ferramenta responsável por registrar e gerenciar toda a sequência de alterações do projeto desde a sua criação, e resolver conflitos entre diferentes versões existentes. Além disso, ele é capaz de reconstruir o estado exato do código-fonte em qualquer versão disponível. É uma ferramenta livre desenvolvida por Linus Torvalds, desenvolvedor do kernel Linux.
Já o GitHub é a central que armazenará seu projeto e o histórico do Git, permitindo a colaboração entre diferentes pessoas/máquinas ou simplesmente garantindo que seu projeto esteja sempre acessível. É um serviço gratuito adquirido pela Microsoft.
Em suma, você utiliza o Git para registrar as alterações no seu projeto local e para sincronizá-las com o GitHub.
No próximo artigo desta série, aprofundaremos no modelo mental adequado aos pesquisadores que desejam versionar seu código-fonte.