O artigo responderá à pergunta que causou a perda de tempo para muitos programadores: que estrutura de diretórios deve ser usada para um projeto futuro ou existente? Qual estrutura será a mais ideal, não apenas para a concepção atual do projeto, mas não será tão dolorosa no futuro em termos de expansão do projeto ou divisão em partes?
Raiz
E então começamos o projeto. Que seja o projeto mais fácil do myapp. Criamos um diretório para ele na pasta principal de desenvolvimento (eu tenho esse Devel).
mkdir myapp cd myapp
No futuro, todas as ações estarão dentro do catálogo do projeto principal
Git
Inicializar um repositório vazio
git init
.gitignore
# *.pyc *.pyo **/__pycache__/ # **/config/ # **/data/ **/logs/ # ( ) **/bin/
Leia-me
A próxima etapa é criar o arquivo README necessário. Este arquivo contém a descrição principal e principal de nosso projeto futuro. Alguns criam um arquivo de texto / simples chamado README.txt. Em portais grandes, os repositórios são aceitos para o padrão Markdown com o nome README.md. Eu prefiro html, porque é mais conveniente para mim fazer seleções de cores, incorporar links, fotos e outras mídias multimídia, abrir em um navegador, incorporar partes de código nas tags <pre> e <code>, usar estruturas prontas como o Bootstrap para decoração e outras mágicas fora de Hogwarts. Por conseguinte, o nome README.html
touch README.html
Se o projeto for conduzido por várias equipes, recomendo que cada equipe tenha seu próprio arquivo README dentro de cada módulo, componente, biblioteca, etc. desenvolvido de forma independente.
App
Eu nomeio o diretório principal do aplicativo da mesma maneira que o diretório do projeto. No caso deste artigo, myapp
mkdir myapp touch myapp/__init__.py
Módulos e componentes
Dentro do diretório do aplicativo, __init__.py é criado por padrão, contendo o código de inicialização do aplicativo e conectando todas as partes necessárias ao aplicativo. Em particular, esses são Blueprints para URLs de ramificação única ou namespace para a lógica de um serviço separado, mas com URLs diferentes (um exemplo simples é a criação de um namespace para um serviço de artigo de blog, onde obviamente existem caminhos diferentes do formulário / páginas e / page / ID)
mkdir myapp/bp_component touch myapp/bp_component/__init__.py
ou
mkdir myapp/ns_component touch myapp/ns_component/__init__.py
Modelo de banco de dados
O modelo de banco de dados contém o código de inicialização do banco de dados, bem como as conexões. E, claro, a estrutura de tabelas e relacionamentos. Também é desejável selecionar tabelas em arquivos separados, com base na lógica de negócios do aplicativo. A descrição de várias classes de tabelas e links em um arquivo separado é conveniente porque você pode reutilizar facilmente o código copiando o arquivo desejado para outro projeto ou usar links simbólicos para o arquivo da biblioteca compartilhada para diferentes projetos.
mkdir myapp/models touch myapp/models/__init__.py touch myapp/models/page.py
Modelos para o mecanismo de modelos
Alguns aplicativos (principalmente aplicativos da Web) são caracterizados pelo uso de modelos para gerar páginas em folha. Como o objetivo principal é separar o código executável da apresentação dos dados, esta etapa ajudará a equipe a economizar muito tempo, esforço e dinheiro, oferecendo a possibilidade de trabalho paralelo de programadores e designers.
mkdir myapp/templates mkdir myapp/templates/html mkdir myapp/templates/js mkdir myapp/templates/css
Observo que, neste caso, os subdiretórios js e css não são para armazenar bibliotecas estáticas JavaScript ou estilos CSS, mas para código mutável, código de parâmetro ou código de incorporação. Por exemplo, se houver um componente de desenho de calendário com funcionalidade adicional conectada aos botões, será muito mais conveniente colocar o componente de calendário em js e habilitar o componente em arquivos html, mas com os parâmetros necessários. Talvez isso pareça uma merda para alguém, mas é muito melhor do que criar uma biblioteca de calendário estática pronta e, depois de meio ano ou um ano, para entender que você precisa adicionar mais algumas três propriedades e métodos ao componente (por exemplo, faça o datepicker não apenas na forma de um mês, mas e adicionar a capacidade de transformá-lo em um calendário por um ano) e que tipo de mágica havia lá dentro, ninguém se lembraria. Inserções darão mais transparência.
Estática
Aqui, todos os principais estilos que nunca mudam (ou mudam extremamente raramente) são estilos, imagens, sons, bibliotecas JS e estruturas.
mkdir myapp/static mkdir myapp/static/css mkdir myapp/static/js mkdir myapp/static/images
Biblioteca de funções
A facilidade de conexão de bibliotecas depende principalmente da linguagem e da estrutura no núcleo do aplicativo. NÃO existem bibliotecas conectadas a partir de repositórios e suportadas por desenvolvedores independentes. Aqui estão suas próprias funções auxiliares. Por exemplo, tenho algumas funções de decorador ao processar uma rota, mas antes de chamar a função principal.
mkdir myapp/lib touch myapp/lib/__init__.py
Definições e configuração
Como armazenar configurações que definem configurações globais de aplicativos? Quantas brigas foram nesse sentido e não contam. Sem detalhes, como faço: armazeno-o como um módulo Python em um diretório separado. Arquivos internos para diferentes modos de inicialização.
mkdir config echo "CONFIG = 'config.devel'" > config/__init__.py touch config/devel.py touch config/prod.py
Por que py? Sim, porque a análise de XML, YAML, INI e outras bobagens, quando é muito fácil criar variáveis do formulário em questão, não passou para ninguém:
import os DEBUG = True TITLE = 'SpecialistOff.NET' DIR_BASE = '/'.join(os.path.dirname(os.path.abspath(__file__)).split('/')[:-1]) DIR_DATA = DIR_BASE + '/data' DIR_FILES = DIR_DATA + '/files' MIMETYPES = { 'gif': 'image/gif', 'jpg': 'image/jpeg', 'jpeg': 'image/jpeg', 'png': 'image/png', 'txt': 'text/plain' } SERVERS = [ {'name': 'server1', 'IP': '8.8.8.8', 'port': '80'} ]
Dados
Arquivos, logs e outros dados carregados durante a operação são armazenados em um diretório de dados separado
mkdir data mkdir data/files
Teste
Módulos de teste e acessórios
mkdir tests mkdir tests/fixture touch tests/__init__.py touch test.py chmod +x test.py
A documentação
Toda a documentação do projeto deve ser mantida separada. Eu uso o diretório doc para isso e o armazeno como páginas estáticas da Web com um ponto de entrada index.html. Isso é conveniente porque eu posso compartilhar um diretório de documentação separado por meio de qualquer servidor web. Ou navegue diretamente do diretório com qualquer navegador da Web (incluindo os de console como lynx, elinks).
mkdir doc touch doc/index.html
Implantação
Tudo depende das tarefas. E nos comentários (na minha humilde opinião) não é particularmente necessário.
mkdir deploy touch deploy/requirements.txt touch deploy/build.sh mkdir deploy/config touch deploy/config/__init__.py touch deploy/config/demo.py mkdir deploy/cron touch deploy/cron/myapp mkdir deploy/docker touch deploy/docker/Dockerfile touch deploy/docker/docker-compose.yml mkdir deploy/nginx touch deploy/nginx/myapp.conf mkdir deploy/uwsgi touch deploy/uwsgi/conf.ini mkdir deploy/uwsgi/conf.d touch deploy/uwsgi/conf.d/myapp.conf
Registo
Aqui você pode adicionar logs para lançamentos de teste ou as conclusões do próprio aplicativo.
mkdir logs
Scripts e utilitários auxiliares
mkdir utils touch utils/useradd.py chmod +x utils/useradd.py
Em vez de uma conclusão
Em princípio, é tudo. Por que sou tão lacônico? Porque o código falará por mim melhor do que eu. O restante dos meus comentários pode confundir ou gerar controvérsia sobre qual abordagem será melhor / pior.