项目迁移的思考

1 改造背景

在过去的一年里，我们做了两次大的项目改造（项目有大概70个页面）：

一次是因为由于业务线快速发展，现有的项目从一开始的孵化慢慢演变成转转的基础业务，除了要在小程序运行外，还要在app端运行，需要个h5版本，于是我们依据原有的mpvue项目新改造了一个vue项目（mpvue说是可以转换成h5，但是如果页面复杂的话根本没法转换）。
另一次也是因为业务发展越来越庞大，我们和主程序及其他业务线会有更多的业务融合，同时还有公共库的复用及更新问题。我们小程序项目是用mpvue写的，而主程序和其他业务线采用的是wepy。每次和其他业务线有合作时候，我们都是重新开发，今年由于公司大方向要做流水，跟其他业务线合作会越来越紧密，为了不让技术栈成为业务线合作的壁垒，我们最终决定，将mpvue项目改造成wepy

2 改造心得

经过这两次大的改造，自己也得出了一些心得，这里跟大家分享一下：

2.1 在迁移、改造的时候，一定要把项目充分的拆分，越细越好

这块是整个工程的核心，也是考验项目负责人对整个项目的熟悉程度

如果哪块不熟悉一定要找对应的负责人询问清楚，再不济自己去看代码

因为后续所有的开发、项目跟进、测试都是依照这一步产出的“蓝图”为依据的，做这一部分的时候要尤为耐心，这块做的细后面的坑就少。

我拆分项目会按照几大块来做：

原有项目痛点思考

在之前的项目中肯定有一些东西设计的不合理，这次正好是个改正的机会，比如：

1） ajax返回结果：我们之前为了方便不用每个页面都处理接口报错的情况，是直接返回data，但是有经常有情况需要根据接口返回的code码来判断，所以这次返回的是{code:xxx, data: {...}}形式

2）新项目引入typescript、采用webpack4

3）新增了gotoPage.js：原来的小程序直接通过path跳转，但是页面多了之后，尤其路径携带的参数很不好管理，经常pm找我要个活动页的链接，path好说，主要是参数不知道有哪些，还得现查代码。于是我们做了一个gotoPage.js，里面给每一个页面都做了个命名，同时注释标明了所有参数意义，调用的时候更简单了，查询的时候更方便了

// 过去
navigateTo({url: URL.setParam('/packageA/pages/activity/publish4RedpackageSuccess/main', {
    channel: 'xxx',
    shareUid: 'xxx',
    fromActiontype: 'xxx'
})})

// 改造后
gotoPage('activityPublish4RedpackageSuccess', {
    channel: 'xxx',
    shareUid: 'xxx',
    fromActiontype: 'xxx'
})
复制代码

4）其他改造点...

项目搭建

项目负责人一定要把项目搭建完成，各种npm包，webpack配置等，这是最基础工作，迁移必须完成
公共库

公共库有很多文件可以直接拷贝过来，最主要的还是基础能力的改造，尤其新老项目中，一些基础能力不通用的，都要进行改造，同时，老项目基础库中哪些需要引入引入公共包也都要罗列出来，比如：

1）登录：登录前置、登录后置

2）ajax封装：这块是不是需要变更库（如axios）来处理，接口请求是否需要强制登录，各种状态码处理，以及返回的数据结构

3）cookie：小程序cookie处理和h5项目cookie处理是不一样的，cookie名字变更

4）支付

5）图片上传

6）统计上报

7）h5特有文件

8）通用业务逻辑的处理
通用组件

所有通用组件，要一一罗列
页面

页面这块主要是要整理哪些页面已经下线（通常是活动页面，如果已经下线，就不在本次改造、迁移范围内，可以直接减少工作量，下线页面需要做一个下线提示）

然后把本次需要迁移的页面和做下线处理的页面分别罗列出来

好了，这些都搞定之后，我们可以列出一个大的excel表格

表格里把每一项都罗列清楚，根据原有项目代码为每一项估算一个时间

注意： 估算时间这块，项目负责人要根据组内实际平均单日有效时长做评估。

比如：按一天早十晚七算，部分人早上会迟到一会，中午要午休一会，晚上完饭散个步等等，实际单日有效时长可能只有6小时

当然我们组的有效时长要高于这个时间，负责人要根据自己组的实际情况进行评估。（这也是反复推敲后才能确认的）

敲定每一项的时间后，计算出一个总时长，这里需要根据实际需要，要额外打一定的buffer时间（我这里打了10%，从67.4天最终定为74天）

2.2 分工上已经要明确

根据上面的excel把每个人负责的内容明确出来，（原来分方向负责人照旧）

但有一点，是公共部分的分工，一定要明确！！！

比如同一个公共能力或者公共组建，A、B、C三人都用到了，一定明确到底谁做，别小看这个，我第一次改造就吃了这个亏了，一开始大家只做自己那部分，公共部分都等着，最后拖延整体的时间。

人员分工完成之后，并不是最终版，还要根据每个人的投入时间进行二次修改

2.3 人员投入时间上要明确

人员投入上要明确，每个人在什么时间点才能投入进来，什么时间点会请假等等

比如项目组有A、B、C、D、E五人：

A立即可以介入，月底请2天假
B立即可以介入，不请假
C后天才能介入，下月初请3天假
D5天后才能介入，月底请1天假
E一周之后才能介入，不请假

然后根据每个人的实际时间对上述表格“负责人”进行修正。

==原则：尽量保证大家在同一时间点结束项目开发。==

2.4 对改造初稿进行评审

这别以为其他leader不熟悉自己的项目，就认为这步是多余的。

经过评审之后，leader们会给出很多建设性意见：

尤其公共库和组件库这块，哪些能力有，哪些能力需要改造，会沟通的非常清楚（因为公司业务比较庞大，所以有很多的公共库），对于之前项目里没有的能力，如果公共库支持的话，会非常节省时间，同时还知道这部分是谁负责的，接入时候遇到问题可以直接找对应负责人。

在这个过程中也可以把自己的想法和大家沟通一下，你项目中的部分改进意见没准也是其他组需要的。

如果有条件一定拉着大家评审一下。

2.5 上线时间沟通

这一部分尤为重要，在完成上述步骤后，已经可以大概估算出时间了（通常大项目可以估算测试时间为开发时间的一半）

拿我们这次为例：

74人/日开发量，37人/日测试量，FE 5人，QA 3人（本次是前端框架迁移，不涉及server端）估算一下，开发需要18个工作日，QA需要15个工作日，算上周末，大概就是一个半月时间。

通过这个时间同领导和业务方进行沟通，看看这个时间是否可行，如果OK，那没什么说的，如果不OK，就要考虑加班了。

在加班也解决不了问题的时候，就得向领导求助了，需要其他组的支援。

以我们为例，我们最多只有5周的时间，而且加班也搞不定（因为年底调休，每周要上六天班，再让大家过来加一天班显然不合适），于是找领导协调过来一个成员，支援我们一周。

那么新来的成员不了解业务，他能做什么呢？

只能给他做业务逻辑相对简单的页面，比如：搜索推荐、搜索结果页、个人主页等，然后再去调整整个项目的人员分工

2.6 进度跟进

对于大型项目改造，每天要向成员询问进度，稍不留神拖个几天很常见

及时更新表格里的“开发进度”，也让自己心里有底

白色：表示尚未开始
蓝色：表示开发中
绿色：表示已经完成

测试也采用同样的方式

2.7 测试介入方式

对于大型项目，可以采用分批提测的方式。

这样可以让QA资源最大化利用。

测试中每天要向QA获取测试进度，获知bug修改速度，中间有没有遇到问题。

我们就用这种方式最终项目耗时1个月零3天，提前2天上线。

2.8 为什么用excel，2个原因：

最主要是：因为框架迁移是技术驱动，写需求文档是个功夫活，罗列测试点的时候尤其的麻烦。

这个表格列的很细致，有哪些页面、功能需要测试一目了然，可以直接发给QA。他们在测试进度那一栏直接分工，同时每天也可以通过标明不同颜色跟踪进度。
excel大家电脑都有，不用再专门安装软件

总之就是这个表格做完可以帮你省很多事

OK，以上就是最近的一些思考，分享给大家，欢迎一起交流