本文仅仅是对前几个月使用React重构百度新闻webapp项目的一个总结和思考，不会泄露任何项目代码（文章中的代码都是或其他开源产品的配置代码，fis3是百度开源产品），因此“伸手党”可绕行。

现在2016年8月，web前端技术这几年变化太快，因此一些信息的时效性非常重要，还是把时间写上比较好。

百度新闻的 webapp 有两个途径可以访问。第一个是用手机浏览器访问 点击搜索框下面的“新闻”链接，第二个是下载手机百度app，搜索框下面有个“新闻”链接。每天平均的PV，大概接近1亿。

也可以手机浏览器直接输入/news或者扫描下面的二维码。本次重构代码于2016年08月08日上线，数字还挺吉利！

重构一个项目需要很多条件的支持，但是最终的目的，是为了：第一减少维护和二次开发的成本、第二提高产品的用户体验或完善功能，两者至少要符合一个，否则没必要重构。不是为了重构而重构，为了技术而重构。

要重构一个项目，特别是一个比较复杂的项目，是需要一些条件的，否则一般都会维护现有版本的产品。比如好多公司的app、网站做的很炫很漂亮，而公司内部的erp、oa、cms等系统都用着10多年前的代码。新闻webapp虽然看似就是一个很简单的新闻列表、新闻分类、新闻内容页，但是详细分析起来还是蛮复杂的。总结起来，重构新闻webapp的条件有这么几个：

• 目前代码比较混乱、代码之间耦合太多，从2011年做完这一版开始，经历了好几个人维护；
• 框架比较老（backbone + zepto），已经落伍，使得维护人员很没有认同感；
• 那段时间产品经理的需求不是很多，开发人员正好有大量的时间；

以上原因中，第三个是最重要的，否则大家都每天加班很晚，谁会再去考虑重构这事儿？既然有时间，那就做吧！我就主动跟我们组长提出了这个事儿，得到他的赞同之后，我们就就开始了下面的内容。

重构的第一步就是选择一个比较靠谱的前端框架。现阶段你如果要做一个webapp，再说什么框架都不用，就用 上找到。

一般情况下，编译ES6都用babel，编译jsx也有相应的工具，但是没成想这两个只需要用typescript这一插件就搞定了。速度还要快，不过编译打包，速度慢一点也没关系，不考虑这个因素。但是使用typescript确实很方便。

// 项目中所有的业务代码都放在 ./app 文件夹下面
/news?tn=gethotnews的数据，这样是不是就一步搞定了！下面说说该如何操作。
 
 

 

 此外，fis-conf.js中还需如下配置，意思是./test和./config两个文件夹下的内容，打包时候要按照既定的路径打包。即 ./test/data.js这个路径，打包之后还是./test/data.js这个路径。
 
 

 
 

 这个需求也是我们开发中必须的。例如，我们要为上线打包文件时，需要让js有md5后缀（为了方便缓存），文件要压缩到最小；而我们要自测打包的时候，就无需md5后缀（否则一天下来产生很多冗余文件），文件不要压缩（否则无法在浏览器调试）。
 
 

 
 

 
 

 
 

 

 是否使用 npm 生态
 
 

 其实这里不应该是一个问题，不过当时有一个小小的纠结，就顺便在这里记录一下吧。
 
 

 
 

 
 

 但是当时就这个用法，出现过一个纠结，即这样依赖，我们打包的third.js文件中，会有很多define语句，都是和React相关的。因为用 npm 安装的 React 也是有好多零散的文件组成的，并不是就一个 React.js。然后，就开始担心这么多“冗余代码”会不会导致代码文件大很多，就开始想其他解决方法（其实最后根本不是问题）
 
 

 
 
 

 
 

 
 

 这样是能解决很多个define的问题了，因为没必要define了，只有一个react.min.js文件，还define个什么劲？
 
 

 
 

 后来，这个解决方案还是被我否决了，当时也没想出什么压倒式的理由，但是有一个原因——没人这么用！大家都在基于npm生态，社区中的写法基本已经固定了，现在却不这么写，自己独创一个写法，那样会越走越窄。哪怕会有那么一点的不完善，我也要按照大家通用的格式来，不要独创。
 
 

 其实后来想了一下，按照解决方案那种使用react.min.js的方式，也是有很多问题的。例如，开发模式下也用.min.js那样就没有React自带的提示、警告功能了，万一忽略了什么性能问题，没有提示和警告，可就麻烦打了。再例如，这样一来就没有版本管理了，前端框架更新很快，版本管理很重要。
 
 

 最后，我们发下经过各种压缩，最后的third.js都不到100kb，完全满足我们的要求————这个年代，真的用不着自己去创新。
 
 

 

 
 

 要降低系统设计的复杂度，前端目前最好的方式就是组件化。将系统划分成若干个页面，然后将每个页面都划分成若干个组件，还要抽象出多个页面中都会用到的通用组件，这是第一步。接下来要看组件和组件之间如何传递数据，即数据管理和状态管理该如何做。下面我们就从这两个方面来分先一下新闻webapp该如何设计。
 
 

 
 

 下图是一个最基本的设计理念，实际项目中也是按照这个来细化、扩展最后落地执行的。即，先给页面划分组件，然后组件构成页面，最后页面匹配路由。如下图：
 
 

 
 
 

 将这个落实到页面上，就是这个效果
 
 

 
 
 

 但是最后在开发过程中忽略了一个问题，就是一些复杂页面（例如，用浏览器模拟手机查看效果），光这种“页面 -
 组件”的形式是不够的，应该在加一个subpage层，这样就扩展性更好一些了。如下图：
 
 

 
 
 

 总结：一个项目总会遇到个别的比较复杂的页面，因此这种page - subpage - component会更加合理一些，其中的subpage在不需要的时候省略掉就是了。
 
 

 智能组件 VS 木偶组件
 
 

 在 React + Redux 结合作为前端框架的时候，提出了一个将组件分为“智能”和“木偶”两种
 
 

• 智能组件：它是数据的所有者，它拥有数据、且拥有操作数据的action，但是它不实现任何具体功能。它会将数据和操作action传递给子组件，让子组件来完成UI或者功能。这就是智能组件，也就是项目中的各个页面。
• 木偶组件：它就是一个工具，不拥有任何数据、及操作数据的action，给它什么数据它就显示什么数据，给它什么方法，它就调用什么方法，比较傻。这就是木偶组件，即项目中的各个组件。

 

 
 
 

 因此，数据在page层获取、数据的操作和处理在page层定义，组件就是傻傻的知道执行和显示就行了，各操各的心。这种设计也整好符合目前无论是Vue、augular还是React提倡的基于数据驱动的设计理念——程序定义好Model和View的关系，剩下的业余处理只需要关心数据变化，View的变化由框架自动执行，无需像jquery时代再去手动操作DOM。
 
 

 
 

 下面看一下数据在系统中是如何传递的。这里的数据分为两种：
 
 

• 第一种可以称之为“系统数据”，和业务无关的，一般任何系统中都会有。例如用户id、用户头像、配置信息等，这个的特点就是符合单例模式，全局共用一套
• 第二种可以称之为“业务数据”，每个页面都可能不一样。如在娱乐频道需要的是娱乐新闻列表，而到了军事频道就需要军事新闻的列表了，再到新闻详情页就需要新闻的内容了

 

 针对这两种不同的数据，当然要分开处理。针对第一种“系统数据”，系统一初始化就立即获取，然后交给Redux做管理，这也符合Redux的特点。而针对第二种“业务数据”，那就什么时候用，就什么时候获取。
 
 

 
 
 

 

 
 

 使用React + Redux设计代码结构，目前方式都比较统一，基本都是按照以下方式来设计，这些在github等社区都能找到相似的结构。
 
 --components // 定义项目中的各个组件，里面可能有很多个子文件夹
 --config // 项目配置，无具体规定，自由发挥
 --fetch // 定义项目中所有数据获取、提交的方法
 --util // 工具函数，例如时间格式的处理等
mocha // 测试用例，一般叫 test ，但是使用 fis3 时候 test 文件夹有其他用处，不得不换个名字
 

 以上目录中，app/components和app/container是开发中修改最多的目录。app/container里面定义的都是页面，即智能组件，只关心数据，功能比较单一，因此结构也比较简单
 
 

 但是针对组件app/components来说，要显示样式，当然就需要css和图片，文件类型比较多。因此，要按照如下方式定义组件
 
 

 即，用一个文件夹来表示单个组件，里面的index.jsx是业务和模板代码，style.less是样式，img/文件夹放图片文件。这样的话，可以把每个组件都作为一个整体来管理，而且引用的时候也比较方便，例如import LoadMore from
 


 

虽然我没法将源码的目录结构截图出来分享给大家，但是我们实际开发中的目录结构基本是按照这个方式来做的，可能就是细节上因此会因为业务的问题做了特殊处理，但是设计理念上是一样的。

 

 开发 - 如何多人协作开发
 
 

 上文已经描述了一些基本配置和系统设计的解决方案，接下来即可进入开发。由于不是一个人做，因此必须考虑如何高效率的多人协作开发。其实这不是一个技术问题，这里就简单写一下这方面的心得体会吧。
 
 

 
 

• 提前定义好代码结构，统一各个文件夹的作用
• 提前设计Router规则，以及和页面的对应关系
• 提前抽象出可能在多个页面中通用的组件，创建文件夹（占位置）
• 讨论确定每个页面都如何拆分组件，统一设计思路

• 每人开发不同的页面，遇到页面单独用的组件，即自行开发；
• 遇到多页面公用的组件，先同步组内开发进度，有则直接用，没有则自己开发；
• 每装配好一个组件，都提交一次代码，随时开发、随时提交、随时合并；

心得：如果你要参与一个重构项目，你只需要按部就班发挥自己的技术能力即可，按照规则编码、测试、提交代码等。但是如果你要自己组织、规划一次系统重构，考虑的事情那就太多了。除了顶住外在的压力之外，还得考虑如何让这件事儿更快、更稳定的运行起来。

 

 
 

 使用fis3作为构建工具，其实使用fis3 server start即可启动本机的服务，然后进行测试。但是像新闻这种产品，它的任何页面都需要获取数据再展示，因此测试的时候需要一些模拟的或者真实的数据，这个fis3也支持，在上文介绍fis3配置的时候已经说明了。
 
 

 但是这种本机运行、并用fis3动态假数据模拟的情况有一个问题：它没法模拟登录的情况，http请求中也没有登录状态下的那些cookies信息，这就会影响很多功能的测试。因为新闻的许多功能是需要登录才能运行的，例如个人收藏、订阅频道、评论、点赞等。
 
 

 最终想到的一个办法是将代码放在公司内部的一台测试机上，然后通过测试机访问，这样就可以获取登录信息。因此这里介绍一下如何使用fis3将代码发布到测试机上。fis-conf.js中做如下配置：
 
 

 配置完了之后，执行fis3 release remote，它就会执行编译，并且将编译后的文件传上去。然后再在测试机上配置一个服务，支持页面的访问即可。
 
 

 

 
 

 代码检查是开发环境中非常重要的一步，其实这块的配置很简单，之所以单独列出来，就是为了体现它在开发过程中（特别是多人协作）的重要性。
 
 

 项目中使用eslint做检查，其主要配置文件有两个。.eslintignore定义了忽略哪些文件的检查，例如我们要忽略一个第三方插件的代码检查
 
 

 还有一个.eslintrc.json定义了代码的检查规则，本项目的检查规则相对比较宽松，配置如下。其配置项的意义，在网络上可以轻松查询到。
 
 

 最后，我们将检查代码的命令封装进package.json中，如下代码。这样，在检查的时候，只需要运行npm run lint这个简单命令即可
 
 

 目前只是软性的规定，在git commit之前必须做检查，如果开发人员忽略了，也能将代码提交上。接下来将考虑将代码检查强制做到git-hook里面，即git commit之前必须要检查通过，否则无法提交。
 
 

 

 
 

 上文说过，自测的时候，发布的代码是未经过压缩、也未加md5后缀的，而且直接将代码发布到服务器的目录即可，无需存到指定目录。但是要打包出一个目录，然后将文件提交给测试人员，就和自测不一样了。
 
 

 首先，打包的文件要压缩、要加md5后缀（上文讲述fis3的配置的时候已经说过）；其次，要讲文件打包到指定目录，这里定义将文件打包到./release目录下；第三，fis3的默认release功能还会将开发环境的源文件一起打包了，这些是不需要的（仅仅需要合并出来的代码即可，合并的代码在./release/static目录下）。将以上这些需求一整合，写一个复杂的命令一起放在package.json中
 
 

 这样，执行npm run publish即可生成一个./release文件夹，里面包含了最终的模板文件、编译之后的js和css、以及处理之后的图片文件。目录结构如下。最终，将这个文件夹提交给测试人员部署即可。每个公司都有自己的提测流程，百度内部流程这里就不说了。
 
 

 
 
 

 测试过程中，qa可能会有反馈bug，至于如何修复bug，以及如何进行二次开发和维护，我都写了一个（仅供百度内网访问），规定了每个步骤该如何执行。
 
 

 

 
 

 测试完了之后要上线，每个公司的上线步骤也都不尽相同，有的高级一些，有的low一些，这里就不管了。
 
 

 上线之后注意如何及时快速的回滚，这一点很重要。
 
 

 

 
 

 洋洋洒洒写了好多，最后做一个简单的总结。
 
 

 系统重构的目的永远都是为了后面减少开发成本、提高系统性能和稳定性，这是公司或部门需要的结果。对于实际执行的个人来说，参与或发起重构项目，是对自己如何掌控一个产品前端设计和架构的一次很好的机会，会对自己有很大的能力提升。重构过程中会遇到一些预想不到的问题，思考在过程中解决这些问题，对自己又是另一方面的能力提升。因此，好的东西，都是双赢的。
 
 

 
 

• 继续压榨性能：无论是通过资源的懒加载，还是使用Immutable.js做不可变数据，都要让性能达到最优

 

 
 

 选择React框架肯定要再试图往两个方向来攻：
 
 

我这测试没有问题。请试试如下解决方法：
1.对比系统自带的IE是否能打开。如果也打不开请换个时间再试试。或在搜狗浏览器右下角的第一个加速器按钮上点击，选网络优化。
2.如果IE能打开，请在搜狗浏览器里按CTRL+F5强制刷新，或在地址栏右边切换浏览模式试试。
3.如果IE正常，两个模式都打不开，请在搜狗浏览器右上角的网络连接上点击-选使用IE的代理设置，并重开浏览器试试。
4.关闭相关广告过滤类插件，或安全软件功能大全里的广告过滤。以及浏览器保护。
5.修复安装最近的新版搜狗浏览器4.1，在右上角的菜单-帮助-浏览器修复工具-手动修复-选重置加速策略和清理临时文件。