为什么要设计好目录结构?
“设计项目目录结构”,就和"代码编码风格"一样,属于个人风格问题。对于这种风格上的规范,一直都存在两种态度:
可读性高: 不熟悉这个项目代码的人,一眼就能看懂目录结构,知道程序启动脚本是哪个,测试目录在哪儿,配置文件在哪儿等等。从而非常快速的了解这个项目。
可维护性高: 定义好组织规则后,维护者就能很明确地知道,新增的哪个文件和代码应该放在什么目录之下。这个好处是,随着时间的推移,代码/配置的规模增加,项目结构不会混乱,仍然能够组织良好。
所以保持一个层次清晰的目录结构是有必要的。更何况组织一个良好的工程目录,其实是一件很简单的事儿。
假设你的项目名为foo, 我比较建议的最方便快捷目录结构这样就足够了:
目录结构示例
Foo/
|-- bin/
| |-- foo
|
|-- core/
| |-- tests/
| | |-- __init__.py
| | |-- test_main.py
| |
| |-- __init__.py
| |-- main.py
|
|-- logs/
|
|-- docs/
| |-- conf.py
| |-- abc.rst
|
|-- setup.py
|-- requirements.txt
|-- README
解释:
bin/: 存放项目的一些可执行文件,也可以起名script/之类的。
core/: 存放项目的所有源代码,也可以命名为项目名,如foo/。(1) 源代码中的所有模块、包都应该放在此目录。不要置于顶层目录。(2) 其子目录tests/存放单元测试代码; (3) 程序的入口最好命名为main.py。
logs/: 用于存放日志文件。
docs/: 用于存放一些文档。
setup.py: 安装、部署、打包的脚本。
requirements.txt: 存放软件依赖的外部Python包列表。
README: 项目说明文件。
关于README的内容
README是简要描述该项目的信息,让读者快速了解这个项目。
它应该要说明以下几个事项:
软件定位,软件的基本功能。
运行代码的方法: 安装环境、启动命令等。
简要的使用说明。
代码目录结构说明,更详细点可以说明软件的基本原理。
常见问题说明。
关于requirements.txt和setup.py
setup.py
一般来说,用setup.py来管理代码的打包、安装、部署问题。业界标准的写法是用Python流行的打包工具setuptools来管理这些事情。这种方式普遍应用于开源项目中。不过这里的核心思想不是用标准化的工具来解决这些问题,而是说,一个项目一定要有一个安装部署工具,能快速便捷的在一台新机器上将环境装好、代码部署好和将程序运行起来。
安装环境时经常忘了最近又添加了一个新的Python包,结果一到线上运行,程序就出错了。
Python包的版本依赖问题,有时候我们程序中使用的是一个版本的Python包,但是官方的已经是最新的包了,通过手动安装就可能装错了。
如果依赖的包很多的话,一个一个安装这些依赖是很费时的事情。新同学开始写项目的时候,将程序跑起来非常麻烦,因为可能经常忘了要怎么安装各种依赖。
setup.py可以将这些事情自动化起来,提高效率、减少出错的概率。"复杂的东西自动化,能自动化的东西一定要自动化。"是一个非常好的习惯。
setuptools的文档比较庞大,刚接触的话,可能不太好找到切入点。学习技术的方式就是看他人是怎么用的,可以参考一下Python的一个Web框架,flask是如何写的: setup.py
当然,简单点自己写个安装脚本(deploy.sh)替代setup.py也未尝不可。
requirements.txt
这个文件存在的目的是:
方便开发者维护软件的包依赖。将开发过程中新增的包添加进这个列表中,避免在setup.py安装依赖时漏掉软件包。
方便读者明确项目使用了哪些Python包。
这个文件的格式是每一行包含一个包依赖的说明,通常是flask>=0.10这种格式,要求是这个格式能被pip识别,这样就可以简单的通过 pip install -r requirements.txt来把所有Python包依赖都装好了。
本文讨论了Python项目中设计良好目录结构的重要性,包括提高可读性和可维护性。建议的目录结构包括bin/、core/、logs/、docs/、setup.py、requirements.txt和README。setup.py用于项目的安装、部署和打包,而requirements.txt则记录了项目的依赖包。良好的目录管理和自动化工具可以提升项目管理效率。
515

被折叠的 条评论
为什么被折叠?



