Orientação a Projetos

Henrique C. Costa

2019-12-10

Um novo formato: uma estrutura orientada a projetos

Uma estrutura de projeto lógica, razoavelmente padronizada, mas flexível para realizar e compartilhar trabalhos de análise de dados.

Não estamos falando de fazer ciclismo na estética da indentação ou nos padrões de formatação pedante - em última análise, a qualidade da estrutura de aqrquivos na análise de dados é sobre correção e reprodutibilidade.

Quando pensamos em análise de dados, geralmente pensamos apenas nos relatórios, insights ou visualizações resultantes. Embora esses produtos finais geralmente sejam o evento principal, é fácil focar em tornar os produtos com boa aparência e ignorar a qualidade do código (estrutura de execução/metodologia) que os gera. Como esses produtos finais são criados programaticamente, a qualidade do da estrutura de execução ainda é importante! E não estamos falando de fazer ciclismo na estética da indentação ou nos padrões de formatação pedante - em última análise, a qualidade da estrutura de arquivos da análise de dados é sobre correção e reprodutibilidade.

Não é segredo que boas análises geralmente são o resultado de explorações muito dispersas e aleatórias. Experimentos “experimentais” e abordagens de teste rápido que podem não dar certo fazem parte do processo para obter as coisas boas, e não há uma bala mágica para transformar a exploração de dados em uma progressão simples e linear.

Dito isto, uma vez iniciado, não é um processo que se presta a pensar cuidadosamente sobre a estrutura do seu método de excução ou layout do projeto; portanto, é melhor começar com uma estrutura lógica e limpa e cumpri-lo por toda parte. Acredita-se que é uma grande vitória ao usar uma configuração bastante padronizada como esta. Aqui está o porquê:

Outras pessoas vão agradecer

Ninguém fica parado antes de criar um novo projeto para descobrir onde eles querem colocar suas opiniões; apenas rodam project_teplates para obter um esqueleto de projeto padrão como todo mundo.

Uma estrutura de projeto padrão bem definida significa que um recém-chegado pode começar a entender uma análise sem se aprofundar nas teorias e na imensidão dos dados, basta rápidas consultas na documentação e dicionários. Isso também significa que eles não precisam necessariamente ler 100% da estrutura do projeto antes de saber onde procurar coisas muito específicas.

O projeto bem organizado tende a ser auto-documentado, pois a própria organização fornece contexto para o seu projeto sem muita sobrecarga. As pessoas vão agradecer por isso porque podem:

  • Colabore mais facilmente com você nesta análise;
  • Aprenda com sua análise sobre o processo e o domínio;
  • Sinta-se confiante nas conclusões às quais a análise chega.

Um bom exemplo disso pode ser encontrado em qualquer uma das principais estruturas de desenvolvimento web, como Django ou Ruby. Ninguém fica parado antes de criar um novo projeto para descobrir onde eles querem colocar suas opiniões; eles apenas rodam project_teplates obter um esqueleto de projeto padrão como todo mundo. Como essa estrutura padrão de projeto é lógica e razoavelmente simples na maioria dos projetos, é muito mais fácil para alguém que nunca viu um projeto específico descobrir onde encontraria as várias partes móveis.

Outro ótimo exemplo é o padrão de hierarquia de sistemas de arquivos para sistemas semelhantes ao Unix. O diretório /etc tem um propósito muito específico, assim como a pasta /tmp , e todos (mais ou menos) concordam em honrar esse contrato social. Isso significa que um usuário da Red Hat e um usuário do Ubuntu sabem aproximadamente onde procurar certos tipos de arquivos, mesmo quando usam o sistema um do outro - ou qualquer outro sistema compatível com os padrões para esse assunto!

Idealmente, é assim que deve ser quando um colega abre seu projeto de análise de dados.

Você vai agradecer

Já tentou reproduzir uma análise que você fez alguns meses atrás ou mesmo alguns anos atrás? Você pode ter estruturado o seu projeto, mas as vezes é impossível decifrar o que foi feito e se você deve usar-lo novamente para fazer as novas anaálises. Aqui estão algumas perguntas que aprendemos a fazer com uma sensação de medo existencial:

  • Devemos inserir e/ou juntar a coluna “X” aos dados antes de começarmos ou isso veio dessa forma da fonte?

  • Pense bem: em qual modelo; análise; ou arquivo precisamos executar primeiro antes de executar as plotagem (gráficos): eram “dados de processo” ou “dados limpos”?

  • De onde os shapefiles foram baixados para os gráficos geográficos?

  • Et cetera, vezes o infinito.

Esses tipos de perguntas são dolorosas e são sintomas de um projeto desorganizado. Uma boa estrutura de projeto incentiva práticas que facilitam o retorno ao trabalho antigo, por exemplo, separação de preocupações, abstração da análise como DAG e melhores práticas de engenharia, como controle de versão, documentação e dicionários.

Nada aqui é obrigatório

Discorda de alguns nomes de pastas padrão? Trabalhando em um projeto que é um pouco fora do padrão e não se encaixa exatamente na estrutura atual? Prefere usar um pacote diferente de um dos (poucos) padrões?

Vá em frente! Essa é uma estrutura leve e pretende ser um bom ponto de partida para muitos projetos.

A consistência dentro de um projeto é mais importante. A consistência dentro de um módulo ou função é a mais importante. … No entanto, saiba quando ser inconsistente. Às vezes, as recomendações do guia de estilo simplesmente não são aplicáveis. Em caso de dúvida, use seu bom senso. Veja outros exemplos e decida o que parece melhor. E não hesite em perguntar!

Um novo estilo

Com isso em mente, a proposta de um modelo de estrutura orientada a projetos de análise de dados para sua análise não precisa estar no Python, R, Julia, Power BI ou qualquer outro framewokr, mas o modelo fornece alguns clichês de metodologias de projetos de Data Science que você precisa conhecer.

Estrutura Orientada a Projetos

├── LICENÇA
├── LEIAME.txt          <- Arquivo LEIAME, com um resumo geral do projeto.
├── dados
│   ├── externo       <- Dados de fontes de terceiros.
│   ├── canon        <- Dados canônicos finais que foram transformados para modelagem.
│   └── raw            <- Os dados originais e imutável (dados primários).
│
├── docs               <- Dicionários de dados, manuais e todos os outros materiais explicativos do projeto.
│
│
├── BK
│   ├── rascunhos       <- Todos rascunhos
│   ├── Back-ups        <- Qual coisa que deseja salvar para não perder.
|
|
├── relatório            <- Análise gerada como MS Word, PDF, HTML, LaTeX, etc.
│   └── figuras        <- Gráficos e figuras gerados para serem usados nos relatórios.
│
├── requisitos.txt   <- Explicando as ferramentas e habilidades necessárias para reproduzir o ambiente de análise, por exemplo: dashboard gerado com Power Bi, etc.
│
├── src                <- Pasta contendo o código fonte para uso neste projeto.
│   ├── __init__.???    <- Script Mestre.
│   │
│   ├── dados           <- Scripts para baixar ou gerar dados (API).
│   │   └── make_dataset.???
│   │
│   ├── features       <- Scripts para transformar dados brutos em recursos para modelagem.
│   │   └── build_features.???
│   │
│   ├── modelos         <- Scripts para treinar modelos e depois usar modelos treinados para fazer previsões.
│   │   ├── predict_model.???
│   │   └── train_model.???
│   │
│   └── viz  <- Scripts para criar visualizações exploratórias e orientadas a resultados.
│       └── viz.???
│
└──

Os dados são imutáveis

Nunca edite os dados brutos, especialmente não manualmente e principalmente no Excel. Não substitua seus dados brutos. Não salve várias versões dos dados brutos. Trate os dados (e seu formato) como imutáveis. O código que você escreve deve mover os dados brutos através de um pipeline para sua análise final. Você não deve executar todas as etapas toda vez que quiser criar uma nova figura, mas qualquer pessoa deve poder reproduzir os produtos finais apenas com o que tem dentro da pasta src e com os dados inseridos na pasta data/raw onde ficará os dados brutos.

Seja cauteloso ao alterar a estrutura de pastas padrão

Para manter essa estrutura amplamente aplicável a muitos tipos diferentes de projetos, acredita-se que a melhor abordagem é ser liberal ao alterar as pastas do seu projeto, mas ser conservador ao alterar a estrutura padrão de todos os projetos.

Criou-se um rótulo de layout de pasta especificamente para problemas que propõem adicionar, subtrair, renomear ou mover pastas. De maneira mais geral, também criou-se um rótulo de discussão de necessidades para questões que devem ter uma discussão cuidadosa e de amplo suporte antes de serem implementadas.

A estrutura baseada em projetos de Data Science é opitativo, mas não tenha medo de usa-lo. As melhores práticas mudam, as ferramentas evoluem e as lições são aprendidas. O objetivo desta estrutura orientada a projeto é facilitar, inicialmente, a estrutura e o compartilhamento de uma análise.