Django Apps Checklist

Useful checklist for build great Django apps. Access Github Repo.
python; django;
Checks are saved in your local storage

1. Conceitos

  • Verifique se seu app segue a filosofia Unix: "Faça uma coisa, e faça bem";
  • Verifique se a descrição do seu app encaixa em poucas palavras. Exemplos:
    • django-taggit: django-taggit a simpler approach to tagging with Django;
    • django-js-reverse: Javascript URL handling for Django that doesn't hurt;
    • django-impersonate: Simple application to allow superusers to "impersonate" other non-superuser accounts.
  • Verifique se a descrição do seu app tem a palavra "e", e caso tenha, tente quebrar em mais aplicações.

2. Fácil para Instalar

  • Crie um arquivo LICENSE;
  • Distribua no PyPI:
  • Publique em Django Packages;
  • Instale dependências automaticamente:
    • Adicione dependências em install_requires no setup.py;
    • Não adicione Django em install_requires;
    • Não coloque versões com == em install_requires. Use >=.
  • Verifique se você precisa de uma aplicação Django ou um pacote Python regular;
  • Aplicações Django precisam ser adicionados em INSTALLED_APPS. Pacotes python não;
  • Exemplos de pacotes Python:
  • Tenha padrões sensatos e inteligentes:
    • Torne-o um padrão;
    • Não obrigue copiar e colar de trechos de código;
    • Não faça nada perigoso por padrão, como caching.
  • Exija que o comportamento inseguro seja explícito:
    • Não exiba tudo se algo não estiver definido, exemplo: fields = None não deve significar todos os campos.
  • Tenha propriedades declarativas para habilitar uma fácil configuração:
    • Adicione um prefixo para todas as propriedades da aplicação, como MYAPP_SETTING_KEY;
    • Converta parâmetros internos hardcoded para propriedades:
      • Por exemplo, AVATAR_MAX_SIZE do django-avatar deve ser hardcoded, mas ele é uma configuração;
      • Se é necessário frequentemente por desenvolvedores, habilite o comportamento para ser alterado com somente uma alteração na configuração;
      • Se é necessário frequentemente por desenvolvedores, aceite classes customizadas e funções nas configurações via dotted path;
        • Por exemplo, django-taggit suporta tag parsers customizados via configuração.
  • Suporte pipelines declarativos para workflows configuráveis;
  • Cheque a implementação de python-social-auth;
  • Providencie views padronizados com templates e URLs para habilitar a aplicação para ser incluída facilmente;
  • Tenha uma política de upgrade amigável:
    • Torne deprecated antes de remover. Para raise deprecation warnings, use o módulo warnings do Python.
    • Não reescreva migrações:
      • Os usuários podem depender dos seus antigos arquivos de migração, porque eles rodaram no passado.
    • Mantenha um CHANGELOG;
    • Siga o Versionamento Semântico;
  • Dê créditos, tenha um arquivo AUTHORS:
    • Verifique este script para gerar um arquivo AUTHORS a partir do histórico do seu repositório GIT.

3. Fácil de Usar

4. Fácil para integrar

  • Reduza descontinuidades na integração:
    • Quebrar comportamentos de classes dentro de métodos;
    • Separar comportamento de classes dentro de mixins;
    • Isolar lógica dentro de módulos helper com funções e classes de negócio.
  • Use AppConfig:
    • Verifique se seu aplicativo não interrompe quando o AppConfig é estendido.
  • Providencie templates padrão:
    • Não coloque diretamente dentro de templates/, mas coloque dentro de templates/app_name/;
    • Garanta que podem ser alterados carregando algum template personalizando com o mesmo caminho.
  • Providencie template tags para apresentar dados complexos
  • Deixe apenas lógica de apresentação dentro de template tags, quebre o resto da lógica dentro de helpers. Por exemplo:
    • django-avatar tem um avatar template tag para gerar tags img, mas a lógica para gerar URLs avatar é isolado em providers.py;
  • Providencie views padrão:
    • Não quebre a configurabilidade dos class-based views. Permita que os atributos e métodos existentes nas views do Django sejam sobrescritos;
    • Quebre lógica de views em comum dentro de mixins.
  • Evite models built-in se possível. Caso precise tê-los, providencie um model abstrato e habilite sua aplicação de trabalhar com uma variedade de customizados concretos. Exemplos de implementação:
  • Quando usar Generic Foreign Keys, permita que eles sejam substituídos por FKs diretas. Exemplos de implementação:
  • Isole lógica de campos form dentro de form fields e widgets:
  • Isole e lógica de campos model dentro de model fields:
  • Isole lógica de query dentro de métodos queryset, como filter, update e delete;
  • Isole lógica de comportamente a nível de tabela, dentro de métodos manager, como lógica do create;
  • Isole lógica de validação dentro de validators;
  • Use context processors somente para lógicas globais;
  • Use middlewares somente para lógicas globais relacionados ao ciclo request-response ou current user;
  • Evite código spathetti nos signals.

5. Manutenção

  • Seja transparente sobre bugs, especialmente problemas de segurança;
  • Não abandone o projeto, give it away.

Yay! You completed the checklist top to bottom!
Now spread the ❤︎ by thanking the author, making improvements or creating you own checklist!