Capítulo 3 Desenvolvendo Rotinas de Pesquisa
No capítulo anterior aprendemos a utilizar o R e RStudio para operações básicas tal como a criação de scripts, manipulação de objetos no R, mudança de diretório de trabalho, entre outras. Antes de passarmos para a importação de dados, é necessário discutirmos como organizar uma rotina de pesquisa no seu computador.
Neste capítulo iremos tratar das etapas de pesquisa e a organização de arquivos no computador, incluindo dados e rotinas. O principal objetivo aqui é mostrar e justificar um formato de trabalho que facilite o desenvolvimento e compartilhamento de código. Por exemplo, ao abrir um diretório de projeto antigo, a própria estrutura dos arquivos e pastas já indicará como o mesmo funciona e quais as suas entradas e saídas.
3.1 Etapas de uma Pesquisa
Um script de pesquisa pode ser organizado em quatro etapas consecutivas:
Importação dos dados: Dados crus (originais) do mundo real são importados para a sua sessão do R, seja de arquivo local ou da internet. Neste momento, nenhum tipo de manipulação de dados ou reformatação manual deve acontecer. Como regra de bolso, dados crus nunca devem ser tocados. Deixe toda e qualquer manipulação para a etapa seguinte.
Limpeza e estruturação dos dados: Dados importados na fase anterior são processados em uma etapa de limpeza e estruturação. Registros anormais e erros em observações são eliminados ou tratados das tabelas originais. Novas variáveis de interesse são criadas com base nos dados importados. A estrutura dos dados originais também pode ser refeita de acordo com a necessidade. O resultado final dessa etapa deve ser, preferencialmente, uma tabela final com todos os dados necessários para a análise do problema.
Visualização de dados e teste de hipóteses: Após limpar e estruturar os dados, o próximo passo é realizar a análise em si, a qual será visual, através da criação de diversas figuras, ou então com a estimação de modelos e testes de hipótese. Essa etapa refere-se ao próprio problema da pesquisa. Na grande maioria dos casos, essa é a fase que exigirá maior trabalho, visto que representa o coração da pesquisa. Essa etapa termina com a criação de arquivos, tal como uma figura com extensão .png, que serão utilizados na etapa seguinte.
Reportando os resultados: A última etapa é a criação dos objetos de interesse a serem reportados no artigo ou relatório. Esses objetos geralmente referem-se a tabelas e figuras, que podem ser exportados como arquivos externos e futuramente importados em um relatório.
Cada uma das etapas anteriores pode ser estruturada em um único arquivo .R ou em vários arquivos separados. O uso de vários arquivos é preferível quando as etapas de cada pesquisa demandarem muito tempo de processamento. Por exemplo, na importação e organização de uma base de dados de grande volume, vale a pena separar os procedimentos em arquivos diferentes. Isto facilita o encontro de erros e manutenção do código.
Um caso prático seria a análise de dados volumosos de transações financeiras no mercado de capitais. A importação e limpeza desses dados leva muito tempo. Uma organização inteligente da estrutura da pesquisa seria dividir as etapas em diferentes scripts do R e, usando arquivos locais de dados como “pontes”, lincar um script com outro. Assim, a rotina de importação e limpeza de dados salva um arquivo .rds no final de sua execução, o qual é importando no script de teste de hipóteses. Desta forma, uma mudança na modelagem do problema não exige que todo o processo de limpeza dos dados seja refeito. Essa simples organização de arquivos economiza bastante tempo. A lógica é clara: isole as partes da pesquisa que exigem muito tempo de execução – e pouco de desenvolvimento –, e conecte as mesmas com o resto do código usando arquivos externos de dados, tal como arquivos .rds e .csv.
Caso você for trabalhar com diversos arquivos, uma sugestão é criar uma estrutura de nomenclatura que defina as etapas da pesquisa. Um exemplo seria nomear o código de importação de dados como 01-Import-and-clean-data.R, o código de modelagem como 02-build-report-models.R e assim sucessivamente. O efeito prático é que o uso de um contador na primeira letra do nome do arquivo faz com que a ordem de execução do programa fique clara. Indo além, você pode criar um script mestre chamado 00-run-it-all.R que roda (comando source) todos as outras rotinas. Assim, toda vez que realizar uma atualização nos dados originais, você pode simplesmente executar 00-run-it-all.R e terá os novos resultados, sem necessitar rodar cada script individualmente.
3.2 A Estrutura de Diretórios
Uma estrutura de organização de diretórios também beneficia a reprodutibilidade e organização da pesquisa. Para rotinas simples, com uma base de dados única e um baixo número de procedimentos, não é necessário dispender muito tempo pensando na organização dos arquivos nos diretórios. Para programas mais complexos, onde existem diversas etapas de pesquisa e diversas bases de dados, uma segmentação dos diretórios é não somente recomendada como essencial.
Uma estrutura de diretórios que considero eficiente é criar um diretório único para a pesquisa e, dentro dele, criar subdiretórios para cada elemento de entrada e saída. Por exemplo, você pode criar um subdiretório chamado data, onde todos os dados originais serão guardados, um diretório figs e um tables, para onde figuras e tabelas com resultados de interesse serão exportadas. Para funções utilizadas na pesquisa, você pode também criar um diretório chamado R-Fcts. Todos os scripts principais da pesquisa, e nada mais, devem ficar na raiz do diretório de pesquisa. Um exemplo da estrutura de arquivos seria:
/Capital Markets and Inflation/
/data/
stock_indices.csv
inflation_data.csv
/figs/
SP500_and_inflation.png
/tables/
Table1_descriptive_table.tex
Table2_model_results.tex
/R-Fcts/
fct_models.R
fct_clean_data.R
0-run-it-all.R
1-import-and-clean-data.R
2-run-research.RO código de pesquisa também deve ser independente, com todos os arquivos disponíveis em uma subpasta do diretório raiz. Se você estiver usando muitos pacotes diferentes, é aconselhável adicionar um comentário nas primeiras linhas de 0-run-it-all.R que indica quais pacotes são necessários para executar o código. A forma mais amigável de informar é adicionando uma linha comentada que instala todos os pacotes necessários, como em # install.packages ('pkg1', 'pkg2', ...). Portanto, quando alguém recebe o código pela primeira vez, tudo o que ele (ou ela) precisa fazer é retirar o símbolo de comentário e executar a rotina. Dependências externas e etapas para a instalação correta do software também devem ser informadas.
Os benefícios deste formato de diretório são os seguintes. Se você precisar compartilhar o código com outros pesquisadores, basta compactar o diretório em um único arquivo e enviá-lo ao destinatário. Após descompactar o arquivo, a estrutura da pasta informa imediatamente ao usuário onde deve alterar os dados originais, a ordem de execução dos scripts na pasta raiz e onde as saídas são salvas. O mesmo benefício acontece quando você reutiliza seu código no futuro, digamos, daqui a três anos. Ao trabalhar de forma mais inteligente, você será mais produtivo, gastando menos tempo com etapas repetitivas e desnecessárias.
Seguindo a sugestão de um script mestre, um exemplo comentado para o conteúdo do arquivo 00-run-it-all.R seria:
# clean up workspace
rm(list=ls())
# close all figure windows created with x11()
graphics.off()
# load packages
library(pkg1)
library(pkg2)
library(pkg3)
# change directory
my_dir <- dirname(rstudioapi::getActiveDocumentContext()$path)
setwd(my.d)
# list functions in 'R-Fcts'
my_R_files <- list.files(path='R-Fcts',
pattern = '*.R',
full.names=TRUE)
# Load all functions in R
sapply(my_R_files,source)
# Import data script
source('01-import-and-clean-data.R')
# run models and report results
source('02-run-research.R')Essa é a primeira vez que usamos as funções graphics.off e sapply. A primeira fecha todas janelas de gráficos abertas. Essas tendem a acumular no decorrer do trabalho e devem ser fechadas no início de um novo script. O comando sapply aplica uma função, nesse caso source, para uma série de elementos. O efeito prático em sapply(my_R_files, source) é que todos arquivos com extensão .R localizados na pasta R-Fct serão executados. Ou seja, todas funções que escrevermos nos arquivos fct_models.R e fct_clean_data.R serão carregadas em nossa sessão de trabalho. Futuramente, capítulos 10 e 8, iremos voltar ao assunto de uso de funções customizadas.
Note que, assumindo que todos os pacotes já estão instalados no computador, o script 00-run-it-all.R é facilmente compartilhável e irá rodar em outro computador com nenhum problema. Caso o leitor quiser ir um passo além, pode também utilizar a função file.copy para copiar todos os arquivos de figuras para a pasta de escrita do artigo ou documento acadêmico. A partir disso, crie um link no texto para cada arquivo copiado anteriormente. Como exemplo, no LaTex você pode incluir um arquivo de figura com o comando \includegraphics{filenamehere}. Pode também criar um link direto entre o arquivo de escrita e a figura da pesquisa, apesar de esse método não ser recomendado, uma vez que ele cria uma dependência externa ao arquivo de escrita. Em ambas as formas, todas as figuras da pesquisa serão automaticamente atualizadas no texto e estarão sincronizadas com os arquivos provenientes do código da pesquisa. Para tabelas, a importação não é tão simples, pois uma tabela pode ser escrita em diversos formatos. Existem, porém, pacotes específicos para lidar com isso. No capítulo 12 estudaremos uma forma eficiente de reportar resultados utilizando os pacotes xtable (Dahl et al. 2019), texreg (Leifeld 2022), entre outros.
3.3 Pontos Importantes em uma Pesquisa
Aproveitando o tópico de execução de pesquisa, vou colocar aqui algumas sugestões para a realização de pesquisas com o R. Deixo claro que essas são posições pessoais, oriundas das minha experiência de trabalho. Muitos pontos levantados aqui são específicos para o ambiente acadêmico, porém podem ser facilmente estendíveis para a prática de pesquisa fora das universidades.
Em primeiro lugar, conheça os seus dados! Entendo que o primeiro instinto ao se deparar com uma nova base de dados é instantaneamente importá-la no R e sair realizando análises. Aqui, um certo nível de cautela é necessário. Toda vez que se deparar com um conjunto de dados novos, se pergunte o quanto você realmente conhece esses dados:
- Como os dados foram coletados? Para que fim?
- Como estes dados se comparam com dados já utilizados em outros trabalhos?
- Existe alguma possibilidade de viés na forma de coleta dos dados?
Lembre-se que o propósito final de qualquer pesquisa é a comunicação. Certamente irás reportar os resultados para pessoas que irão ter algum tipo de opinião informada sobre a pesquisa. É provável que os avaliadores terão mais experiência que você no assunto, incluindo sobre as fontes e individualidades dos dados. Não desejo para ninguém estar em uma situação onde um esforço de pesquisa, com investimento de 3 a 6 meses de trabalho entre programação e escrita, é anulado por um simples lapso na checagem dos dados. Infelizmente, isso não é incomum.
Portanto, seja muito cauteloso sobre os dados que estás utilizando. Um detalhe que passa despercebido pode invalidar toda uma pesquisa. Caso tiver sorte e a base de dados vier acompanhada de um manual escrito, destrinche o mesmo até os últimos detalhes. Elenque as principais dúvidas em relação aos dados e, em caso das informações não estarem claras, não seja tímido em enviar os questionamentos para o responsável.
O segundo ponto é o código. Após terminar de ler este livro, o seu computador se tornará um poderoso aliado em fazer realidade as suas ideias de pesquisa, por mais gigantescas e mirabolantes que forem. Porém, um grande poder vem acompanhado de grande responsabilidade. Um erro de código pode facilmente inviabilizar ou tendenciar a sua pesquisa.
Lembre que analisar dados é a sua profissão e a sua reputação é o seu maior ativo. Caso não tenhas confiança no código produzido, não publique ou comunique os seus resultados. O código de sua pesquisa é de total responsabilidade sua e de mais ninguém. Verifique e questione o mesmo quantas vezes for necessário. Seja, sempre, o avaliador mais criterioso do seu trabalho:
- As estatísticas descritivas das variáveis relatam fielmente a base de dados?
- Existe alguma relação entre as variáveis que pode ser verificada na tabela descritiva?
- Os resultados encontrados fazem sentido para a literatura atual do assunto? Caso não, como explicá-los?
- É possível que um bug no código tenha produzido o resultado encontrado?
Ainda me surpreendo como pesquisas submetidas a respeitados periódicos podem ser negadas a publicação baseado em uma simples análise da tabela descritiva dos dados construídos. Erros básicos de cálculos de variáveis são facilmente encontrados para um olho treinado, que sabe onde procurar. Esse processo de avaliação contínua da sua pesquisa não somente o deixará mais forte como pesquisador(a) mas também servirá de treino para a prática de avaliação de pares, muito utilizada na pesquisa acadêmica. Caso não tenhas confiança suficiente para reportar os resultados, teste o seu código ostensivamente. Caso já o tenha feito e ainda não estás confiante, identifique as linhas de código que tens mais dificuldade e busque ajuda com um colega ou o seu orientador, caso existir. Este último é um forte aliado que pode ajudá-lo com a sua maior experiência.
Todo o trabalho de pesquisa é, de certa forma, baseado em trabalhos já existentes. Atualmente é extremamente difícil realizar algum tipo de pesquisa que seja totalmente inovadora. O conhecimento é construído na forma de blocos, um sobre o outro. Sempre existe uma parcela de literatura que deve ser consultada. Particularmente para o caso de pesquisa em dados, deves sempre comparar os seus resultados com os resultados já apresentados na literatura do assunto, principalmente quando é um estudo replicado. Caso os resultados principais não forem semelhantes aos encontrados na literatura, questione-se o porquê disso. Será que um erro de código pode ter criado esse resultado?
Deixo claro que é possível sim que resultados de uma pesquisa sejam diferentes dos da literatura, porém, o contrário é mais provável. O conhecimento disso demanda cuidado com o seu código. Bugs e erros de código são bastante comuns, principalmente nas primeiras versões das rotinas. É importante reconhecer este risco e saber administrá-lo.
3.4 Exercícios
Q.1
Imagine uma pesquisa envolvendo a análise do seu orçamento doméstico ao longo do tempo. Dados estão disponíveis em planilhas eletrônicas separadas por mês, durante 10 anos. O objetivo da pesquisa é entender se é possível a compra de um imóvel daqui a cinco anos. A partir disso, detalhe em texto os elementos em cada etapa do estudo, desde importação dos dados até a construção do relatório.
As possíveis etapas do estudo são:
Importação 01: Importar todos os dados relativos à renda e orçamento familiar, taxa de retorno em investimentos – renda fixa ou renda variável – e históricos de preços de imóveis nos locais desejados;
Limpeza 01: Limpe os dados para outliers e dados faltantes (NA);
Manipulação 01: Use os dados de renda pessoal para encontrar a necessidade de economia mensal para cada ano.
Manipulação 02: Com base nos retornos históricos dos investimentos em renda fixa/variável e na inflação do imóvel, verifique quantos anos leva para economizar a quantidade de dinheiro necessária para comprar o imóvel.
Q.2
Com base no estudo proposto anteriormente, crie uma estrutura de diretórios em seu computador para acomodar a pesquisa. Em um arquivo texto na pasta raiz da pesquisa, assinale arquivos fictícios para cada subdiretório (veja estrutura de diretórios no início da seção 3.2). Note que a criação dos diretórios pode ser realizada pelo próprio R.