1. 代码风格
Python项目需遵循PEP8的规则
如果代码内部注释写的不详细，请在各个变量或者函数起名的时候用完整通用的英文单词，可读性会比较强，给之后维护人员留点活路
2. Readme.md文件
要求用markdown语法书写，语言由此项目所用的region来决定（文档类的都一样，如下不再敖述）
此文件的目的是任何人在打开这个项目后根据readme里面的内容可以把此项目完整run起来，请考虑好里面应该写啥，别瞎写
3. Contribute.md 文件
由每个项目的owner来确定需要完成什么样的步骤才可以来提交自己的代码，如是否进行过了单元测试
4. Changelog.md文件
在每次大变动或者添加全新的功能的时候请做好版本控制，并把改变的内容在此文件中列出
最后要的效果是在项目结束或者拿到某一个版本的时候通过这个文件能知道当前版本都支持什么样的功能
5. 需求列表
由于不少需求网络性/抽象性和自主性比较强，不少同事在遇到模糊的需求的时候会不知所措，因此各个项目我会安排人来写需求文档，目前以GitLab中的issues模块为媒介来做
确定性的需求会以issues方式提出来，但探索性和尝试性的需求除外
6. 架构设计
为了尽量避免经常重构，有些重构是设计的时候就可以避免的，因此在每个项目甚至每个需求开始做之前请及时的沟通清楚
需要有设计图（PPT/Visio/XMind等都可以）
7. 虚拟开发环境
默认用virtualenv来实现，里面可以安装多个python环境，并且互相不冲突也和系统级别的环境不冲突，有利于测试
用reqirement.txt文件来标识此项目安装所需要用的所有包和包的版本，在在线安装的时候用pip –r requirement.txt一条命令完成所有环境安装
8. Git Branch的使用
大家使用的时候都有一个问题，分支是以功能为单位的，而不是以人为单位的
Master分支要和对应的现网Demo项目同步
9. 稳定分支/Production等保护性分支
此分支是和稳定版本而对应的分支
10. Tag的使用
11. Milestone的使用
在项目周期比较长的时候需要用milestone来确定需求在哪一期才开始做，由项目owner来定
可以完整的记录在此milestone期间遇到的所有issue，做了一个完整的记录
12. Merge request template和Issues template
都是GitLab的功能，能规整大家书写的格式，能使接受者清晰的知道你要merge的内容变化和issue具体的内容
13. 单元测试
在多人协作，模块繁杂的项目中，保证每个模块自身的正确性非常重要，前端也需要做单元测试
用unittest来实现python后端单元测试，前端或者其他语言也会有针对的单元测试方法
用converge来实现测试覆盖率
14. 功能测试
基于每个业务上的功能写专门的测试代码来测试功能的准确性和完整性
15. 自动化工具Tox
通过配置可以实现测试集成，不同版本，不同环境来测试代码的可用性
16. 自动化部署平台
GitLab Runner CI是一个非常好的自动化部署平台，可完全管理起整个项目从提代码/测试/部署等，只有通过了才可以提交
17. 自动化部署
通过shell脚本来实现自动化部署
可以用docker来具体实现，或者git来具体实现
18. Offline部署
由于绝大部分客户都没有网络，因此在offline部署的时候和Lab里部署有不少区别
如果允许，直接传一个OVA虚机给客户是最直接的方式，也是最简单的一种方式
由于不少工具需要整机部署，并且绝大部分银行客户不会让你拿一个全新的虚机放到他们的现网中，因此需要在客户现场根据客户提供的任何Linux操作系统来实现安装
根据Anacada 和requirement.txt里涉及到的包来实现这种情况下的部署
如果在一台虚机上部署的工具较多，用supervisor来做进程管理，很方便的一个包
19. API文档/项目开发文档/项目功能介绍文档等
独立的API文档可以用markdown来书写，并放到代码库里
层级结构复杂的文档需要用sphinx来实现
20. .gitignore
和项目自身无关的log，元数据，生成的output等都需要排除在代码库外
测试时生成的测试文件等也需要排除在外
虚拟环境也需要排除在外
程序编译后的文件也需要排除在外