1. 产品重构预知
在贯彻及执行产品重构之前，至少如下三点要做到了然于胸。
1.1 充分理解当前架构
首先做到充分理解当前架构和各种业务场景及需求。
1.2 明确重构的原因
分析架构重构的理由和其他备选方案，明确重构的目的是为了满足业务需求，并且是不得不做的最佳方案，然后再考虑其他问题。有时候，经过分析就会发现，也许还有其他解决方案，比如增加计算资源，或者重构的目的不是为了业务需求，那就没有必要做了。
1.3 明确重构的目标及边界
如果确定要重构，那么要把目标明确下来，也就是重构的边界条件，怎么才算是“完成”了重构，目标要有数据量化，或者有能够测试的办法。这也是一个需求分析的过程，如果需求不明确，那么规格说明书没法写清楚，负责重构的团队也没有明确的目标，不能以重构的时间或者主观的判断为结束的依据。
2. 技术评审
决定产品重构后，要做技术评审，至少要做到产品经理、项目经理和产品开发技术人员参与。
2.1 功能需求评审
在重构每个模块时都要进行技术评审包括基础框架类的和功能模块，最好把需求及目标都一条一条的列出来。
2.2 技术选型
进行架构重构时不是时下最热的技术就好，而是要注重实效，要考虑人力及时间成本，看能不能完成此次架构重构的目标。
3. 任务分工
基础设施比如Web框架、数据库选型、中间件、缓存设计等；
各个服务模块业务接口的实现；
通用方法库；
4. 产品重构过程管控
建议把重构过程分成一个个小的迭代，每个迭代的目标和时间都要量化，并且期间要有项目或者产品管理人员来对每个迭代的状态进行把控，比如每天开5-10 minutes的站会或者每周开周会来对每天每周的项目状态进行追踪。
5. 开发规范
因为做后端且偏python，所以从python及相关框架的角度来思考编码规范的问题。
5.1 代码规范自检
代码的风格最好都保持一致，方便后期维护及管理。
比如采用flake8及其插件，插件比如：flake8-commas、flake8-import-order、flake8-quotes、line-profiler等。
5.2 单元测试及覆盖率
方法论
对于开发的Restful API必须都要单元测试，且对接口的覆盖率要达到80%以上。
实践举例说明
基于django框架的API接口的单元测试: form rest_framework.test import APITestCase 从而进一步封装APITestCase。
数据那一块可考虑使用factory-boy
覆盖率：coverage
5.3 代码提交规范流程
git flow
5.4 代码审查及合并
每个方法或接口实现最多不能超过100行，在代码合并之前要assign若干名同事review，待都同意merge后方能执行合并操作。
6. 测试
常规功能测试、压测、回归测试、灰度测试等
7. 线上部署方案
线上肯定得出一套安装部署方案，或半自动化或全自动化，或是将代码打包成二进制文件通过yum、apt-get之类的工具安装、启动服务；或是走容器化；
8. CI/CD
8.1 CI
CI: 可以考虑用gitlab CI来做代码的检查、单元测试甚至代码的构建，这一块涉及到的知识点：.gitlab-ci.yml、docker、gitlab-runner安装注册及使用等；
这一步可能也会涉及到docker私有registry的搭建；
8.2 CD
能够实现快速产品交付和自动将产品部署到开发测试甚至生产环境。
比如考虑用gitlab+jenkins+fabric/shell/ansible脚本的形式来实现。
实现一个CD小demo应该遵循的流程：
-
- docker安装jenkins；
-
- 创建触发任务、参数构建任务、周期性任务；
-
- 分别通过脚本来实现各自任务下项目自动化的部署；