前言
鉴于产品竞争对手步步紧逼的优化升级，自身的服务质量亟需提升，决定拿业务使用频率高的业务线做重构优化，在界面不大变的前提下提高信息提取和展示速度，提升用户体验。
进度
项目大致是从8月底开始介入，至9月底告一段落。项目期间总有：4/人次前端开发工程师、1/人次服务端、3/人次测试、2/人次客户端、1/人次产品、1/人次设计参与。截至9月31日项目完成首次回归测试，处于第二次测试阶段。还有公众号重构、树节点变更、行业数据标签新增等三个新需求处于开发阶段。
风险
- 这次项目是一次完全由技术推动的重构，业务层面的人员参与度不高（几乎没有），这就要求技术重构人员对原有业务的熟悉度极高，毕竟这条业务线已存在3-4年时间，大大小小的需求累积数以千计。由此，对于PRD和PSD的需求极高，由于之前没有累积对应的文档，想要一目了然的了解需求进化非常困难。对于业熟悉的途径本应还有测试文档，可惜的是也没有对应文档留存，单元测试及自动化测试更是没有的，不存在的。这方面原因导致重构完成度很难达到百分百覆盖，细节漏洞百出。
- 对旧源码的理解程度影响整个重构质量。
- 业务需求在重构期间没有冻结。这一点造成开发人员返工现象，例如公众号需求，在重构末段，提出交互、视觉、业务三方面重构，这造成的返工现象给开发人员带来困扰和压力。在整个项目中期，开发人员对于公众号的增删改投入了1-2d的工时，这部分工时的代码只有一部分可重用于末期的重构，大部分都被舍弃。
- 开发人员调动导致中后期开发工时变数。一前端同事负责开发公众号、行业相关，开发未结束即被抽调至其他部门。这一变数使得原本2人负责的前端开发，归为1人负责，至最终工时可控度降低。
- 重构涉及到第三方变动，例如第三方接口输出，第三方数据统计。
需求
- 业务线相关网页重构
- 公众号改版
- 行业财报日历
方案
将原来的iframe改为单页应用，采用前后端分离方案，前端模板渲染
- 框架：React
- 路由：React Router
- Resource：Axios
质量
第一次回归测试已完成，总体质量一般，问题可归类一下：
- 数据回显不正确
- 请求资源不正确
- Form表单提交不正确
- 客户端交互不正确
小结
出于本次首次将React应用于业务线，对框架的不熟悉导致对问题的预见性不高，在前期开发中埋下了许多坑：
- 组件拆分不合理，组件与组件间通信成本过高
- 状态初始化不合理。因为是单页应用，所以整个页面生命周期内信息都不会释放，逐一继承。所以一些路由下应该清空的数据继承了前一个路由生成的数据，这直接导致Form表单提交不正确和请求资源不正确、数据回显不正确的发生率升高。
- 如何给路由组件增添额外的props，这一点在后期开发中凸现出来，由于整个页面是一个组件，左侧树和右侧内容是两个子组件，两个子组件在没有状态中心的情况下通信需要通过父组件中转，最后解决方案是通过路由组件（路由本身是组件）的render props自定义数据传递给子组件，这一点影响订阅和公众号操作。
- 高阶组件的运用不成熟，项目很多功能的开发都能用高阶组件优化，可参考AutoComplete组件。
- 正确处理setState warning，react只能对正在或已经处理完成的组件改变状态，无法对已卸载的组件改变状态
- shouldComponentUpdate方法使用要慎重，处理不当会出现该render的时候不render组件。
- ES6不要滥用，最终还是被ES5实现，反而用babel编译后加入一堆公用代码。
- 多考虑一步会不会埋下不可控隐患，比如业务指定的节点不能用数组索引来定位，不然业务节点变换了原有业务逻辑就不可控。
以上，项目还没有结束，战线拖的长了心累了。