项目迁移的思考

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，以上就是最近的一些思考，分享给你们，欢迎一块儿交流