| 作者 : 京东金融-移动研发部-前端开发工程师 刘麒麟
契子
昨天参加学习部门一同学的react分享会，会上有很多后端的同学参加，大家都对前端有一定的知识积累。于是会上陆陆续续都抛出了同一个共性的问题。“我用传统的开发方式一样能写出来的东西，为何要用react，redux等一些复杂的东西表达出来”。
接触react也有快两年的时间了。RJ、RN都开发过大大小小的项目。借此机会反思起来，突然发现当初感觉是用来装X和有些鸡肋的东西竟有些割舍不开而且散发着深刻的魅力。
众说
一说到为什么选择react，用过的或者网上介绍的一般都是这些优点：
1、view层框架。
[图1]
• 数据试图分离，数据规模大的项目开发便捷。
• 虚拟dom，diff渲染，性能高效。
2、组件化。
[图2]
• 标签化的组件表达方式，清晰。
3、三端。
[图3]
• 这也许是react最吸引人的地方了。一套代码，三端生产。
独白
上面基本是大家耳熟能详的react的优点，下面更想换个角度，宏观点看看react+...
| 分工 - 碎片化的追求
项目工作工作中常遇见有个棘手的问题 - 一个超级大项目但是时间又很急给3人做如何分工？
• 传统的分工：按页面拆分
| 人员 | 页面 |
|---|---|
| 张三 | a、b |
| 李四 | c、d、e |
| 王五 | f、g |
这个分工看似合理，但是这个“合理”也仅仅站在研发的角度。但是一个完整的项目设计到的角色很多，PM，UI，甚至还有BD一类的。这么一看，问题就来了。这个分工每个研发角色都需要和其他各个角色打交道呀。大公司+打交道，你懂的。so，酸爽。那怎么办呢？这个可不碎片化哦。那react能解决吗？
• 引入 react ： 按组件拆分
| 人员 | 功能 |
|---|---|
| 张三 | 组件开发 |
| 李四 | 组件开发 |
| 王五 | 业务开发 |
这个分工让张三和李四逃出了PM和BD的魔爪，让王五一个痛苦去吧。但是呢，来自UI的压力也基本被张三和李四分担了。这个已经很合理了吧，还有优化空间？咱们仔细看一下。 王五是比较累的，因为张三和李四分担了他的不同的功能组件。他在整合业务会和这两人同时打交道。那再来个redux？
• 引入redux ： 数据流管理，组件再拆分动静态
| 人员 | 功能 |
|---|---|
| 张三 | 静态基础组件开发 |
| 李四 | container开发 |
| 王五 | reducer和action开发 |
这下好了，王五负责和PM，BD交涉。李四负责做王五和张三的桥梁。张三不管业务，一门心思和ui同学搞组件。
这就是react+redux的强大，他能让你在分工的时候追求碎片化到极致。虽然看似代码的行数可能没有精简，但是无形中把人员的关系解耦了。
| 规范 - 自律让我自由
看到上面，有的朋友会质疑了。“你这个东西是强拉着和react有关系。说白了就是个项目架构和职责的化分问题。我就是用原生的开发也可以这么划分呀。”
理论上是这样没错。但是所谓框架，就是架构设计的选型承载。它已经为你的这种设计提供了很好的功能api和工程规划。
react提供的这些组件的表达方式，redux提供的组件和数据之间的绑定方式。虽然看上去表复杂，但正像小标题说的那样。因为这些看似复杂的状态对象，生命周期，动作函数。才使得你在组件内部无论什么样的风格，也不会让组件和组件之间（其实也就是开发者与开发者之间）的逻辑传递有任何阻碍。在这套框架下，看似自律了，其实是“自由”了。
| 生态 - 路见不平一声吼
就算结合了上面两点，但是还让你觉得。“无非就是个框架的事儿，不一定非要用react呀。” 那接下来我只有弱弱的澄清一下。
确实不一定非要用react，囧。
据不完全统计，react有比其他类似框架更庞大的周边生态。开发者都明白，真正能让项目开发过程享受便利的一定是好的框架+丰富的库。而这一点，也是react对标竞品的优势所在。
谢幕
最后的最后，说一个笔者自认为比较中肯的悖论。
框架是选型的产物，针对不同的业务产品选择最适合的框架一定是更高的境界。但是，一年中天天都有NBA比赛，全明星能有几场呢？
