Tenho visto muitas pessoas (particularmente meus alunos!) ficarem perdidos nos seus respectivos projetos por falta de organização das informações. Em geral as pessoas ficam perdidas nos montes de arquivos e versões deles, não conseguem achar os arquivos que precisam, ou as versões mais recentes (em um post futuro irei falar também sobre o gitHub), não sabem onde está o mapa ou a tabela que geraram, ou editaram os dados originais e agora não sabem como voltar atrás… coisas desse tipo. Isso lhe parece familiar? Isso está acontecendo com você? Em caso afirmativo, continue lendo que este post pode ajudá-lo!

A primeira coisa que você tem que fazer é criar um diretório (ou seja, uma pasta) para cada um dos seus projetos. Se você está no doutorado, isso provavelmente significa uma pasta para cada um dos seus capítulos. Se você está na iniciação científica, isso deve significar um diretório único. Dentro desse diretório, tudo do seu projeto e apenas coisas do seu projeto estarão! Ou seja, se por exemplo, alguém for colaborar com você, ou se o seu orientador precisar te ajudar em alguma coisa basta você conceder acesso a este diretório, e esta pessoa terá acesso a todas as informações, dados, figuras, textos, análises, etc, realizadas no projeto. Na raíz deste diretório deve constar um arquivo README, que no meu caso eu faço geralmente em Markdown (README.md), mas pode ser em txt, por exemplo. Neste arquivo você deve explicar a organização destas pastas, bem como a organização do projeto (quem são as pessoas envolvidas, objetivos gerais, etc) de maneira resumida (curto!!!). Assim, se alguém obter de alguma maneira esta pasta, saberá do que se trata e como está organizada (ou seja, rapidamente poderá continuar o trabalho de onde você parou).

Bom, mas vamos falar agora da organização interna desse diretório propriamente dito. Uma das pastas internas é a pasta dados, que é uma pasta que estará (após a inclusão dos dados) configurada para apenas leitura (para evitar problemas com os dados) e irá abrigar todos os dados brutos/originais/dados de entrada. Estes podem ser planilhas, mapas, mapas baixados da internet, qualquer tipo de dado. Nessa pasta é também fundamental um arquivo README, onde devem constar todas as informações básicas (metadados mais gerais) de cada um destes arquivos, por exemplo (e o mais fundamental), de onde foi obtido/baixado (como obtê-los novamente), quem coletou etc. Muitas vezes esses dados devem ficar organizados dentro de subpastas (dentro da pasta dados, para organizar melhor), e aí dentro de cada uma destas pastas devem constar os metadados (READMEs) mais detalhados (para mapas por ex. projeção, extensão, fonte, origem, etc). Existem formatos padronizados de metadados, e você pode se beneficiar de conhecer mais sobre isso (ex. EML, para mapas, etc).

Estes dados brutos, antes de serem utilizados, precisam ser tratados/limpos/filtrados, e isso deve acontecer sempre por script, ou seja, de forma automatizada. Esta automação evita erros, e principalmente, facilita (em caso de necessidade) de se refazer futuramente (por ex. foram coletados mais dados, ou seu orientador pediu para fazer diferente!). Após filtrados estes dados são salvos na pasto dados_use (na raíz do diretório), para o uso subsequente nas análises (ou seja, o script “pega” automaticamente os dados na pasta dados, executa os comandos solicitados, e salva os dados limpos/filtrados na pasta dados_use, prontos para o uso). Todo o processo de filtragem/limpeza/edição dos dados deve ser detalhadamente registrado e explicado, e os scripts que executam estas tarefas claramente indicados (padronização da nomenclatura, ver abaixo).

Estes scripts que executam estas limpezas, e os demais scripts com os quais as análises são conduzidas ficam na pasta scripts. Aí ficam todos os códigos de R, Python, Julia, Java, seja lá qual for a linguagem de programação que você está usando. Alguns destes scripts que são utilizados frequentemente, e que executam funções repetitivas, são transformados em funções, e movidos para a pasta funções depois de serem exaustivamente testados (incluir a documentação das funções com roxygen2). Estas funções são então utilizadas nos demais scripts ao longo do projeto, e muitas vezes utilizados em outros projetos também.

Outra pasta que tenho usado constantemente faz algum tempo é a vignette. Nesta pasta os scripts são feitos em formato de “literate programming”, no caso do R por exemplo, em RMarkdown (Rmd), e as rodadas (códigos, resultados, figuras, etc) exportados em html, doc ou pdf em geral. Nesta pasta os scripts em Rmd ficam organizados como capítulos de um livro (RNotebooks)/capítulos de uma análise com uma ordem lógica, desde a limpeza dos dados, até as análises finais e geração de uma determinada figura. Caso os dados iniciais mudem, basta eu rodar estes scripts novamente, que os resultados e figuras são prontamente obtidos. A grande vantagem dos arquivos Rmd é que podemos juntar texto escrito em linguagem humana (ex. Português, inglês, etc) e em linguagem de computador (R por exemplo), de forma que temos tudo o que fizemos detalhadamente registrado, ou o relatório/artigo já pronto quando rodamos o script! Desta maneira, a pasta script fica apenas com alguns pequenos scripts, ou com partes de script que testei antes de virarem funções.

Além destas pastas, existe uma pasta que eu uso para armazenar imagens ou gráficos, que foram gerados pelos scripts (R ou Rmd, por ex), e portanto, são facilmente reconstruídos. Eu chamo esta pasta de figs e em geral uso os resultados que estão nela para uma rápida apresentação ou discussão de idéias. Para qualquer coisa mais elaborada é gerado um Rmd (que eu posso deixar com echo=FALSE e não mostrar os códigos fonte, caso seja apenas para mostrar os resultados, por ex), ou seja, estas figuras são apenas para se ter uma idéia, ou um acompanhamento da evolução dos resultados. Sendo assim, caso eu precise reduzir o tamanho do diretório do projeto, eu posso simplesmente deletar estas figuras, uma vez que as figuras são prontamente geradas através dos scripts. Algumas destas figuras são “publicadas online” através do figshare, podendo receber um DOI (i.e., as pessoas irão saber que fui eu quem gerei) e serem utilizadas por terceiros, por exemplo em apresentações, ou outras formas de comunicação.

Outra pasta que abriga resultados é a pasta output, contudo, nestes casos são armazenados resultados intermediários, como mapas com algum resultado, tabelas de resultados exportados, etc. Em geral eu exporto estes outputs para acelerar simulações futuras (as vezes uso a função cache do Rmd), ou para gerar resultados solicitados por colaboradores. Há também uma pasta contendo documentos escritos que eu chamo de docs. Muitas vezes são documentos gerados inicialmente através de um Rmd e convertidos através do Pandoc em um arquivo doc ou docx. O GoogleDocs e principalmente o MSWord ainda são os editores que tenho usado para finalizar textos mais elaborados, particularmente por causa do gerenciamento das referências (veja meu post sobre gerenciadores de referência). Outra pasta que utilizo é a presentations, que abriga as apresentações sobre o projeto. Estas apresentações podem ser geradas através de scripts Rmd, como por exemplo, através do R presentations, slidify, ioslide_presentations, ou mesmo em apresentações Power Point relacionadas ao projeto. Todas essas apresentações devem da melhor maneira possível estarem associadas a scripts da pasta vignette, ao longo do “caderno de análises de dados do projeto”, ou seja, podem ser facilmente obtidas novamente, editadas, etc.

As vezes tenho dentro do diretório de meus projetos uma pasta de referências bibliográficas associadas ao projeto, de forma a facilitar as citações em documentos Rmd. Outra pasta que aparece em alguns projetos é a src, que contém executáveis ou softwares que eu esteja utilizando no projeto.

Uma coisa importante é que os nomes das pastas não tenham espaço, nem ç, nem nenhum acento. O ideal é utilizar um método padronizado de nomear as pastas, por exemplo, todas com letra minúscula e underline quando necessário (ex dados, dados_use, figs, outputs e não Dados, Dados Use, DadosUse, dadosUse, Figs, Outputs). O nome dos arquivos também deve ser curto e fácil de se entender. Tem pessoas que optam por utilizar um verbo no início, como por exemplo, filtra_sp_menor5.Rmd para filtrar espécies com menos de 5 registros. Outras pessoas usam a etapa da análise precedendo o nome, por exemplo dados_filtra_sp.Rmd, ou analise_riqueza_sp.Rmd. O importante é utilizar um esquema para nomear pastas e arquivos padronizados, e sem caracteres especiais (ç, é, etc).

Boa parte dessas idéias eu peguei da forma com que o pesquisador Carl Boettinger organiza seus projetos veja aqui. Aliás, eu recomendo vocês conhecerem um pouco mais sobre o trabalho do Carl, especialmente da forma com que ele faz ciência aberta (open lab notebook) e de ponta.