平台拆分-计划赶不上变化

拆分的原计划

 上文讲了系统拆分的背景和目的。第一个阶段的目的就是将用户相关的信息独立拆分出来。

但是，既然是重构型的项目，就被加了一些佐料。

1·平台老代码中很多查库操作都是select  *，这种操作对性能很不友好，所以领导要求遇到select *的地方直接改掉

2·领导希望经过几次重构后，彻底摆脱原有系统的制约，所以将ucenter的边界划的很大，用户收货地址、积分、站内信等也都加了进来

3·原有的系统数据表有很多不合理的地方，这次也一并做了拆分和调整

我们原定的计划：

1·是通过一个月的时间摸底和复盘，将相关的内容数据表重新设计，按照需求输出接口文档；

2·在接口文档的基础上，开发独立的ucenter服务和配套的sdk包；

3·搭建一套数据同步机制，在数据库底层实现新老数据表数据的数据同步；

4·蚂蚁搬家一样，将业务一点一点的对接，由数据同步做数据保证，业务对接一部分就上线一部分。

 

遇到了哪些坑爹事

理想很丰满，现实很骨感。这个项目最终差点成了大型翻车现场。

在一开始项目还能正常进行，不论设计表结构，还是开发独立的服务和sdk，但是在对接原有业务的过程中，“灾难”不断出现。

 　　去除select *

　　领导的一个小小愿望，成了开发人员的梦魇。在处理select * 的过程中，大部分代码都还好解决。

　　但是有些时候，select * 出来的数据结果使用范围及其广泛，甚至有些代码是控制器调用logic，logic再去调用model，model里面查询了select * ， 而这个model还是一个公用方法，全平台到处都在调用，要去掉这种select *，简直是一场噩梦。

　　业务入口找不到

　　经常会遇到一种情况，在一个model或者logic里发现了一处用户信息调用，但是却找不到在哪里调用这个model或者logic的。或者找到了入口url，但是不知道怎么在平台操作才能访问这个url。

　　这主要是因为参与重构的开发人员不是完全了解平台业务（也没几个开发人员能全部了解平台业务），修改了代码，但是找不到业务入口，这直接导致开发人员无法自测，也给后面的测试人员埋下了一个大坑。

　　巨量历史代码，很多废弃代码

　　上文已经说过，平台的文件数量已经达到了14K+，而且有数量不小的废弃代码。这给重构人员带来了不小的困扰，已经废弃的代码如何确认，无法确认的代码就只能一块修改，这无形中增加了很大工作量。

　　反复改，测试的无奈

　　因为工作安排的原因，不同的开发人员负责处理不同角色的用户信息，但是同一段业务往往会涉及到很多个用户角色，这就导致同一段业务代码会有不同的开发人员反复处理多次，这给测试人员带来了不小的麻烦，测过的业务可能没过几天由要测一次。

　　表结构的修改，带来业务概念的变更

　　因为原系统有些表结构不合理，在重构的过程中，也将数据表做了重新设计。另外，用户关系的一个重要概念被重新定义，这直接导致平台很多历史业务代码需要重构，也给重构项目带来了极大的风险。

　　新需求和老业务改造冲突

　　重构改造最终持续了半年之久，在这半年里，新的需求不断开发出来。这也给重构项目带来了不小的麻烦，需要不断的从平台生产代码merge到重构项目的分支上，再针对新的需求做修改，没完没了。

　　统计类需求导致服务接口设计很丑陋

 　　ucenter拆分的目的之一是数据独立管理，但是平台有很多统计和报表类业务，这些业务往往需要横跨用户信息与订单、商品等信息，时间紧迫又需要兼容此类业务，ucenter做了很多妥协和退让。

 　　数据同步不稳定

　　新老表之间的数据同步是基于阿里云的dts来实现的，因为是异构的数据库，所以需要开发人员自己处理数据同步规则。结合我们调整了很多核心业务表的结构，数据同步在前期根本不可靠，也就没办法实现我们原计划的第4项，这也导致了系统必须整体上线，项目风险剧增。

 

最后的执行情况

写这个笔记的时候，ucenter主体已经上线了。项目复盘的时候，核心成员吐露心声说中间有过很多次都想要放弃，好在最后通力合作，还是把这块硬骨头给啃下来了。

第一重构，有很多不满意的地方，但是好在最后也算顺利上线，留下来的问题可以在平时优化。

开发者有句调侃的名言，“撸码一时爽，重构火葬场”，现在相信了。