由商业角度思考react redux

在一个小团队的时候，我们突然灵感乍现，想要做个很棒的产品，我拉来产品，ui，研发小伙伴一说，大家觉得都不错，哇，开始了，我一步一步推进，最后，在灵感与坚持下，嗯，我的 i淘宝出来了,哇， 我的一个小想法改变了人的购物方式，我由此也成了首富，虽然我不在乎钱，哈哈，以上是我yy的…..

后面集团发展的很快，成立了很多部门，个人创新变的越发困难，（创新环境变了），某个员工为了创新，先要由下而上搞定leader, 再去协调产品，研发，运营个个部门，沟通成本特别大，创新成本非常高，我想，这也是阿里决定变革的主要原因之一

so 阿里提出了 “ 小前台，大中台”

看图理解下面这段话

“某个业务部门里面的研发小A，他想做个新业务，在传统组织下，他要搞定的流程，我们来脑补一下，首先自下而上搞定他的Leader，再搞定总监，如果这个组织大到有研发GM，那么再搞定和说服一次。然后开始自下而上配备资源，由上面下命令，产品设计配合，运营市场配合，最后落地到个人配合。就算我们假设当中任何一个环节都赞同了，他费尽千辛万苦搞定了9个关键人，开始落地。这沟通成本有多高？这时间耗费有多长？”在这种玩法下，玩个毛线创新。山头林立资源无法整合

由此我又想的当年的索尼与苹果，索尼有可能成为音乐行业的爸爸（霸主），他却让给了苹果，乔布斯传中提到，索尼音乐是当时5大唱片公司之一，它既有大量版权，又有当时很受欢迎的随声听，唱片在互联网的冲击之下已经没落，大量盗版歌曲肆虐网上，索尼做了什么呢？ 被乔布斯说服加入itunes音乐商店，嗯，现在看来，索尼失误了，它没能很好的调动个个部门来加入变革，而是个个部门为了自己的利益止步不前，我想这也是经验吧

嗯，说了这么多，跟react有啥关系啊，其实，你在写react的时候就相当于在建设一家公司，头部，列表，尾部，个个部分协调，程序以上图组件树的形式绵延下去，数据自上而下一级一级传递，研发a有好的想法，自下而上传到最大公约父组件，最大公约父组件在自上而下传递给其他部门，

so react在写兄弟组件大量交互的时候非常困难

so 变革来了 redux

“小A想要搞个新业务，此时他搞定业务线的老大：给我三个人，我们一起搞业务D。业务线老大想想看，嗯~历史上小A还是蛮靠谱的，做吧。你这几个人负责业务的方向和差异化资源的落地。至于其他的公共资源，直接找公线要吧。于是小A从公线要到了一大堆被公线打磨过很多的公共模块，拼装一下，然后把差异化的部分合进去，开搞！”

redux就是那个公线，所以状态集中处理，组件通过react-redux与公线联系， 组件通过action要求公线改变状态，触发更新，公线提供state给组件所要数据

不难理解，公司在发展过程中会解耦不同的部门，让其各司其职， 就像单独的财务部门一样，这个部门需要用钱，你只需提交申请单就可以（这样会有依据，钱的去向是明了的，你可以理解action了吧），他的解决方案就是整个集团的钱放在一个地方，记住，Single Source of Truth, 即 global state
**
不管是redux跟mobx，他都是全局state， 以实现数据视图解藕，而他们有共同点的地方，就是分治，redux通过reducer的分解，mobx体现在他可以有多个store

当然，这些都是应用程序很大，复杂时，为了解决相应的问题而产生的解决方案，当你只有几个人的团队时，这些显然显得很死板，而耗费精力，所以，使用关键在于你的场景，嗯，