Python语言以简单易懂，上手难度低著称，遗憾的是，很多人保持着轻松上手后的水平，写了很多“面条式的”代码（我也写过很多）。一个项目如果想要写好，以可持续的方式发展，就不能和写练习的脚本一样，除了编程功底，一些保证项目质量的工具也必不可少。不然公司就像是个小作坊一样，以野路子的方式开发，浪费大量的人力，甚至把刚接触 Python 的新人带歪了。本文总结通常一个可持续交付的 Python 项目应该如何开发。这方便的知识也可以通过逛 Github，看一下一些经典的项目（例如 requests，django，sentry）是如何解决这些问题的。
1. 单元测试
王垠曾经说过：
我喜欢把编程比喻成开赛车，而测试就是放在路边用来防撞的轮胎护栏……
在没有测试的项目中写代码，就感觉在没有护栏的跑道上开车，心里很没有安全感。尤其是代码需要重构的时候。要么你要浪费时间每次都自己手动跑一下程序测试一下（测试也是自动化的一种），要么就要自信，相信自己的改动是绝对正确的。
Github 上面的代码就很方便了，有很多公开的服务可以使用，比如 travis，codecov.io 可以用。
私有项目就有点复杂了，需要自己搭建测试环境。之前用过 bitbucket，用我们自己开发的 CI badwolf 。这个是基于 docker 的，项目中有一个 Dockerfile，badwolf 负责以下一些工作：
- 对 PR 和 master 的代码在 Docker 中进行单元测试
- 对评论 “ci rebuild” 的时候重新从 Dockerfile build 一个image
- 3个人 approve PR 之后自动将 PR 合并
CI 要面对一个问题：测试环境和执行测试的命令如何分离？
Travis 是每次都会执行所有的命令，每次推送都会 install 依赖，运行测试。这样的好处是配置简单，配置环境和跑测试用一个文件就够了，清晰明了。缺点是每次都重新安装，速度慢，浪费资源。
badwolf 是只有 rebuild 的时候才会重新构建镜像，否则一直用同一个镜像来测试。这样的缺点是要制定 Dockerfile，并且要处理好环境，每次测试不能有副作用。优点是速度快。
现在我们用的是 Gitlab。Gitlab 有了 Runner 的概念，其实是更适合大团队一起。只要配置好了 shared runner，所有的项目都可以用，runner 跑完了一个去跑下一个，FIFO很公平，也节省了资源。缺点是，我觉得 Gitlab 是配置CI最复杂的，需要自己部署好 Docker 仓库，然后制定 .gitlab-ci.yml文件。
Gitlab其实比较灵活，你可以在Docker提供一个最基本的 Liunx 环境，在 yml 配置文件中写 install 的东西，每次 CI 都去安装。也可以将环境打包在后者，每次需要更新依赖就要重新 build image，但是 push 代码的时候速度快很多。个人偏爱后者。
2. 代码覆盖率
有了单元测试，如何说服同事保证写测试呢？靠价值观肯定是不行的。
对开源项目来说，有很棒的 codecov 可以用，能生成所有代码每一行跑的次数，覆盖率，changes 带来的覆盖率改变，这些都是最基本的功能了，还有什么 Github 机器人，pipeline（如果 PR 下降了覆盖率，或者新加的代码没有覆盖就不能 merge）更是酷炫。
但是对于私有项目来说，要么给钱，要么自己搞。badwolf 这种自己写的CI比较土，我们是直接在项目的最后打印出来 coverage.py 的输出结果，虽然土，但是有用。覆盖率的保证也需要我们的同事在对不好的 PR 下面留言： “testcase please！”
Gitlab 其实也好不了哪里去，除了打在 log 的最后，在它的 project settings 里面还有一个功能，写一个正则表达式，将覆盖率匹配出来显示。还是土了点，至少有点用吧。另外也可以用 coverage.py 生成的 html 报告推送到 pages 上面，这里有一篇教程，不过那样你又要去维护一个 pages 服务器（还要注意不对外网开放）。
3. 代码质量检查
PEP8，flake8，pylint 傻傻分不清楚？看这里吧。
这种东西，一开始会挺痛苦的，后面对团队收益很多。
4. 保护master
组织任何人向 master push 代码。比较理想的情况是，develop 实时部署到 staging 情况，定期发布到 master。
5. issue追踪系统
类似 Github 的 issue，记录 bug 等未解决的问题，现在除了 bitbucket 丑的基本不能用，其余很多都不错的。
6. code review
对于开源项目或者团队合作来说，review 是非常重要的。
很多人觉得 review 太浪费时间了，业务这么紧，没空搞。但是我觉得这是去了解别人工作的一个好机会，并且互相学习，进步特别快。尤其是对一个刚毕业的同学来说，review几乎是快速成长的一条捷径。review由于合并速度，占用大家的时间等原因，慢是慢了一些。但是节省了很多潜在的时间，利远大于弊。
暂时想到这么多，里面每一个项目如果细开去说还有很多细节问题。甚至每一个点都够成立一个技术公司了。
一定要做正确的事情，不要被业务逼得去走歪路。