某CMS项目，用postgresql做存储，用python写的微服务，为前端服务器提供数据，同时，使用基于django的blog系统mezzanine二次开发用于内容管理后台。项目中还有python写的爬虫和各种算法脚本。
系统运行数月余，越发凸显mezzanine很多地方并未为大量数据进行优化，导致系统速度越来越慢。另外，二次开发的mezzanine代码和主代码分别存在两个仓库中，而mezzanine又包含了多个django app导致代码维护难度大，某些业务逻辑常常需要翻查两个代码库的多处位置才能串联起来整个逻辑。而底层表结构也是继承了mezzanine的设计，多有不合理、不合用之处。
遂讨论重构事宜。准备用纯django从头重建整个系统，舍弃mezzanine。同时，借此机会把底层数据表结构重新梳理和定义。
重构前，剖析整个重构要面临的挑战，主要是：
- 要把用到的mezzanine既有功能全部用django重新实现一遍。
- 底层表结构重构，所有微服务和脚本都需要更新数据库操作相关代码。
- 因为项目要求CMS每日都要完成一些新的需求点，所以重构期间如何保证继续每日有新产出是个难题。
商量的策略是：
小部队继续在老系统上开发新功能，保证每日产出。
大部队去做重构工作，重构后追赶小部队，直到赶上。切换系统。
实际执行结果：
为了尽量缩短战线，降低追赶的难度和浪费，初定一周多时间完成。实际只用了3.5天就完成了核心重构和系统切换。
日志：
12.8
上午。讨论重构难点、方案、策略，决定实施。
下午。启动重构，完成django app规划，完成底层数据表重构梳理并实现models。继而基本完成核心内容管理功能。
12.11
上午。收尾核心内容管理功能。验证数据迁移方案。
下午。初步完成微服务修改，在保持接口不动的情况下修改数据访问层以匹配新数据结构。
12.12
收尾微服务、任务队列、离线计算。
Ops在生产环境创建新库，由Sean完成数据迁移。新系统可以在生产库跑起来了。
晚上。Sean把新功能移植到了新系统。
12.13
完成部署配置等准备。
与Sean一起逐一回测数十个微服务。
下午17:30上线。监测到一些bug，逐一解决。
重构成功，系统切换完成。
总体实施时间：8号半天，11、12、13三天，累计3.5天。比原定18号上线提前了5天。
收获：
经验：
- 重构要快，第一要目标明确，第二心中有全盘规划，第三要聚焦最核心功能，尽快上线。周边功能可以留着上线后逐步完善。
- 人不需要多，需要对旧系统和新规划都非常熟悉的人紧密配合。
- 看似十分困难的任务，舍弃细枝末节，抓住要点全力突破，往往会有势如破竹的效果。
教训： - 接口没有Unit Test，无法自动化回测。手工回测费时费力，覆盖不全面，导致有遗漏问题。
- 没有留出时间做发布规划、预发布、测试，导致在生产环境在线调试和解决问题，在切换期间对服务造成一定影响。
