优化计划（TBD）
Code Style
首先安装配置好自动化 pep8 格式化插件，确保所有新提交或有新修改的代码文件都严格的符合 pep8 格式要求。
然后逐步的完善代码注释。
评估：
| 是否影响线上 | 对代码的影响 | 对部署的影响 |
|---|---|---|
| 否 | 小 | 无 |
Package Dependence
分为两大部分，分别是对依赖打包，和对项目自身打包。
对依赖打包
首先可将 submodule 的依赖改为 package 形式，使用 pip 直接从 gitlab 安装。
这个的影响较小，但是线上的代码都需要重新安装一次（所以可以考虑和对项目打包一起做）。
需要：
- 引入版本号机制；
- 修改每一个项目的 submodule；
评估：
| 是否影响线上 | 对代码的影响 | 对部署的影响 |
|---|---|---|
| 是 | 改结构，不改接口和功能 | 修改代码文件夹 |
对项目打包
我们现在的项目代码其实已经不仅仅是分别的脚本了，而是有独立的入口（如 run_task.py）, 有复杂的逻辑和依赖关系。
这种情况下应该将项目做成标准的包格式，编写属于自己的 requirements.txt，
如果是可执行的，就应该编写 __main__.py 或 entry_point 实现命令行的运行接口。
这么做的优点是：
- 完善的版本管理；
- 清晰的程序执行入口；
- 易于安装；
评估：
| 是否影响线上 | 对代码的影响 | 对部署的影响 |
|---|---|---|
| 是 | 改结构，不改接口和功能 | 需要修改 crontab 的语句 |
按功能拆分
现在的代码文件过于平坦，可以按功能拆分为不同的文件夹，将代码分门别类的放好。
这是一步相当大的改动，需要在理解代码逻辑的情况下逐步的分拆整理。 建议在稳定的前提下，逐步的一点点的修改。
建议在熟练掌握 OOP 设计模式后，按照对象设计的理念进行拆分。
可以先拆分巨型函数为数个小函数， 然后再拆分一个过长的文件为几个小文件，将不同的功能逻辑放到不同的文件里， 最后再将功能类似的文件放到相同的文件夹中。
良好的拆分可以更为灵活的开发新功能，而且为引入单元测试提供了方便。
面向对象设计
考虑到目前前后游的逻辑关系越来越复杂，最好开始着手进行对象关系的设计， 不然命令式脚本的编程方法恐怕无法应付日益复杂的需求变化。
在面对新需求时，在开始考虑业务代码实现以前，最好稍微多花一些时间讨论一下整体的逻辑设计。 业务虽然重要，但是必要的程序设计可以更好的服务业务。