是否选择大前端？
虽然现在大前端很热门，是不是适合自己呢？这个需要想一想
技术的广度和深度，哪个优先？
可以简单类比一下，一个人或者一家公司的技术能力是有限的，可以用一个矩形表示。矩形的宽代表技术的广度，矩形的高代表技术的深度。
图
- 大前端是偏向广度优先的，如果在矩形面积一定的情况下，如果宽度变长了，那么技术高度就会变短，产品就会显得粗糙，这是现实的条件限制。
- 如果更看重技术的深度，比如垂直细分领域，那么就不适合用大前端的思路来做。放弃大前端，比如，只做iOS原生版本，那么就可以将技术做得深入一点，产品也会显得更精致。
- 如果能力强，也就是矩形的面积够大，那么可以两方面都做得很好。比如大公司，就是这么干的。其实市面上这些大前端的技术框架，基本上也是大公司搞出来的。比如，Hybrid是微软的；React是Facebook的，Flutter是谷歌的。
技术驱动还是业务驱动？
大前端的优势是效率高，多端一致性好，带来的好处是响应业务的速度快。同样，带来的问题是技术深度不足，产品相对粗糙。比如，大前端思路下的产品，可以合理地推断，产品体验是iOS下降为和Android一致，而不是Android的体验上升为和iOS一致。
- 如果是业务驱动型，那么采用大前端是很好的选择。iOS和Android的双端一致是天然的，iOS的体验稍微下降一点，普通用户也感觉不出来。
- 如果是技术驱动型，那么大前端并不是一个很好的选择。iOS这种强调体验的产品更能体现出技术的深度和先进性。
第一层，组织上的大前端
- 传统的组织方式很简单：iOS一个团队，前端一个团队，Android一个团队，后端一个团队。
- 传统的组织方式侧重于专业化，就是俗话说的一个萝卜一个坑。
- 传统的组织方式的弊端就是部门墙和沟通协调成本高。
- 大前端团队：交互、UI、iOS、Android、前端、后端组成一个团队；
- 大前端团队主要解决的问题就是部门墙，降低沟通成本；
- 大前端团队的主要职责是快速实现业务，多端同时推进；
- 大公司，可以业务导向，根据业务，多建几个大前端团队就可以了。
- 大前端团队的第1管理者是产品经理，推进业务，提供产品需求文档。
- 大前端团队的第2管理者是技术背景的大前端架构师，负责需求文档的实现和推进。
- 大前端团队的管理模式：敏捷管理，产品经理当Product Owner，大前端架构师当Scrum Master
第二层，架构上的大前端
大前端的目标是加大前端技术的比重吗？恰恰相反，大前端的发展方向是“一云多端”，是将业务尽可能多的往后端迁移。前端主要负责界面展示，交互信息采集等内容。
图
后台切换
为了测试和试用，后台需要部署在不同的服务器上。前端，需要保存好几个后台域名地址，并且提供切换方式。常用的方式，比如，连续点击图标或者标题什么的多次，在弹出框中输入密码，进入一个调试页面，进行环境切换。
这种方式运行很好，真正的普通用户能够发现这个调试页面的很少，对测试人员也很方便。
但是这种方式真的好吗？更好的方法，是将环境切换这部分工作迁移到后端，专门提供一层，来完成这个工作。这一层职责单一一点，一旦上线，基本不用改变。各种前端设备，只要连接这个固定后端就可以了，切换工作，在这个切换层来实现就可以了。
BFF
BFF(Backend for Frontends，为前端而存在的后端)
后端技术一旦确定，一般是稳定的，比如现在比较多的就是Java。
- 减少重复：这一层，用的是后端的技术，比如Java，但是，做得业务，却是前端的。那些不涉及界面的，不涉及交互的前端逻辑，一般都可以放在这里做。比如，后端提供的是一个数字的时间戳，但是界面上显示的是年-月-日格式的字符串，那么这种转换工作，在这里做就是合适的。这样做的好处是显而易见的，这里做一层转换，iOS，Android，网页，甚至小程序上，只要直接展示就可以了，能够减少很多重复的工作，提高团队整体效率。
- Demo数据：需求文档出来了，可是后端服务没有好，没有数据，怎么办？傻等，显然是不合适的。没数据，先造几个假数据。一般都是前端开发自己造的，只要界面显示正确就好了。实际上也都是这么干的，能落地，但是实际效果却并不好，开发体验也是很差的。更好的做法是在这个BFF做，并且提供一个简单界面，让测试人员来提供demo数据。将一条条的Excel测试案例，转化为实实在在的demo数据，更接地气。
网关层
这一层应该成为前后端的界面层。各种后台服务，可以做成各种openAPI，由网关层统一管理。BFF层来统一接入，非常合适。对网关层来说，BFF只是一个内部客户而已，最多给一些特殊权限，很好管理。
现在由各种前端直接连网关层是非常不合适的，用起来的感觉实在太差。有些恶心的，在手机端都要维护一个自己的数据库，那要后台干什么呢？
第三层，技术上的大前端
大前端的技术一直在发展，从WebView到ReactNative再到现在的Flutter。目前的Flutter，可以做为一种大前端的技术选择来用。
- 强调双端一致，让iOS的体验降低为和Android一致；
- Flutter一直在发展，只使用一些已经被验证为成熟的技术；
- 界面采用谷歌推荐的风格，组件使用成熟的框架，icon采用谷歌提供的标准icon。专注于业务，而不是专注于交互体验。
- 兼容性交给Flutter框架，而不是自己整。如果这个麻烦不能扔出去，那么还用框架干什么呢？
- 一次编码，多端运行，从一开始就要坚持。采用纯Dart编码，不要采用混合模式。多用pub上的第三方库，少写原生组件。
- 当然，Dart层的自定义封装应该是要鼓励的。
