- 检查你的应用是否遵循 Unix 哲学: "让程序只做好一件事"
- 检查你的应用是否可以被一句话描述,参考:
- django-taggit: 一个易用的基于 Django 的打标签方案
- django-js-reverse: 针对 Django 的 Javascript 链接处理应用
- django-impersonate: 一个用于使超级用户可以"冒充"其他普通用户的应用
- 检查你的应用描述是否介绍多个功能,如果是的话,请将其拆解为多个应用
- 添加 许可证 文件
- 在 PyPI 上发布:
- 检查命名冲突以避免像 django-filter 和 django-filters 的问题
- 使用 Wheels
- 在 Django Packages 上发布
- 自动安装依赖库:
- 在 setup.py 文件中的
install_requires
添加依赖 - 不要在
install_requires
中添加 Django - 不要在
install_requires
中使用==
限制版本,请使用>=
- 在 setup.py 文件中的
- 确认你需要一个 Django 应用还是一个常规的 Python 库:
- Django 应用需要被添加至
INSTALLED_APPS
中,常规 Python 库不需用添加 - 一些常规的 Python 库:
- Django 应用需要被添加至
- 包含健全及设计良好的默认值:
- 默认即可运行
- 不要要求开发者复制粘贴代码片段
- 默认不要做危险的操作,如,缓存
- 危险操作需要被显式的定义:
- 不要在未设置时默认显式全部,例如,
fields = None
不代表所有 fields
- 不要在未设置时默认显式全部,例如,
- 使用明确的 settings 以简化配置:
- 为此应用的所有设置添加前缀,例如,
MYAPP_SETTING_KEY
- 将硬编码的内部参数替换为配置:
- 例如,django-avatar 中的
AVATAR_MAX_SIZE
可以被硬编码,但他被定义为单个配置
- 例如,django-avatar 中的
- 如果开发者经常需要调整行为,也请在配置中调整
- 如果开发者经常需要调整自定义类或函数,也请在配置中通过路径设置:
- 例如,django-taggit 在 settings 中设置自定义 tag 解析器
- 为此应用的所有设置添加前缀,例如,
- 请使用管道声明的方式设置工作流:
- 请查看 python-social-auth 的实现
- 提供默认 views,templates 和 URLs 以简化应用的集成
- 提供友好的升级策略:
- 给参与者以鼓励,提供 作者清单:
- 基于 git 历史记录,使用 脚本 生成作者清单
- 提供文档:
- 先写文档
- 提供自述文件
- 提供快速入门教程,其中包含常见的使用案例
- 区分高级和初级内容
- 使用性别中立的人称代词
- 部署在 Read the Docs 上
- 提供测试:
- 测试 custom user model
- 提供 coverage
- 提供持续集成:
- 使用 tox 在不同 Python 及 Django 版本下测试
- 参考热门项目的 tox.ini 文件,例如,django-filter 和 django-taggit
- 遵循 PEP 8 规范,使用 flake8
- 使用 tox 在不同 Python 及 Django 版本下测试
- 提供样例工程:
- 将应用以 Django 的抽象方式分成 常用文件名 像 views.py,forms.py,fields.py 等
- 在 URLs 命名中遵循模式
resource_action
,例如,password_reset
,product_detail
- 绝不依赖 Django 默认的用户模型,支持 自定义用户模型:
- 参考 django-registration 的实现
- 提供明确的用法:
- 不要隐式的绑定代码与名称或模块,提供注册机制:
- 为开发者提供常用的管理命令:
- 和主项目交互时,请使用
_default_manager
而不是objects
- Be Pythonic:
- 使用生成器进行惰性求值
- 使用上下文管理语句
with
处理未管理的资源
- 预防错误:
- 基于 Django System check framework 提供检查脚本
- 快速失败:
- 如果开发者写错配置文件,抛出
ImproperlyConfigured
异常:- 例如,当开发者忘记在
FilterView
中指定filterset_class
或model
时,django-filter raisesImproperlyConfigured
- 例如,当开发者忘记在
- 当应用传入了不合法的参数时,抛出
TypeError
或ValueError
- 如果开发者写错配置文件,抛出
- 国际化 (I18N) 你的字符串
- 保证集成的连续性:
- 将类行为由不同方法实现
- 拆解类行为至 mixins
- 将业务函数或类中的逻辑拆解至帮助模块中
- 使用
AppConfig
:- 确保扩展 AppConfig 时,应用不会出错
- 提供默认模板:
- 不要将他们直接放在
templates/
下,放在对应templates/app_name/
下 - 确保开发者自定义模板时,相同路径下的模板可以被覆盖
- 不要将他们直接放在
- 提供模板标签去呈现复杂的数据:
- 只在模板标签中保留展示逻辑,其他逻辑请移入帮助模块
- 例如,django-avatar 有一个
avatar
模板标签用于生成 HTMLimg
标签,但是生成头像路径的逻辑 独立于providers.py
- 例如,django-avatar 有一个
- 只在模板标签中保留展示逻辑,其他逻辑请移入帮助模块
- 提供默认的视图:
- 不要破坏 class-based views 的可配置性,保持 Django views 的属性和方法可以被重载
- 提取通用的 views 逻辑至 mixins
- 尽可能避免使用内建的 models:
- 如果必须使用,请提供一个 abstract model,并为你的应用提供对应的变种实现,一些实现如下:
- 提取通用的 models 至 abstract models
- 不要使用 model mixins,使用 abstract models:
- 通用外键应该可以被直接外键覆盖,一些实现如下:
- 隔离 form field 逻辑至 form fields 和 widgets:
- 隔离 model field 逻辑至 model fields:
- 隔离查询逻辑至 queryset,如,filter,update 和 delete
- 隔离表级别逻辑至 managers,如,create
- 隔离校验逻辑至 validators
- 只把 context processors 用于全局逻辑
- 只把 middlewares 用于涉及全局逻辑的请求-响应循环或当前用户
- 使用 signals 以避免意大利面式代码
- 坦率的对待 bugs,尤其是安全问题:
- 在变更日志中加入安全警告,确保他们可以被 safety 解析
- 不要废弃项目,可以捐给社区