本人从事移动与大前端的工作，最近有时间将自己的部分工作进行总结，现在分享出来。本人毕业后在广东一家大型社交互联网公司从事手机管理工具开发，后来短暂在一家创业公司工作，之后一直在杭州一家大型互联网公司从事电商业务开发。我的经验总结和自己的业务场景有很深的关系，如您观看后觉得有不对之处敬请谅解，如有沟通互动的需要，请联系我的邮箱 413726408@qq.com
我们前台同学实际工作中，做的最多的事情是信息的表达，尤其是传统的图文信息表达，也就是页面开发，大家经常戏称自己的页面仔。
实际上是有很多帮助我们提升研发效能的理论与实践，MVC，MVP，MVVM，MVI等眼花缭乱的概念和事件，本质都是希望抽象出一种可扩展可复用的结构，帮助大家提升效能，降低开发成本。这样大家几乎所有的交互都会落在这个架构上，再在这个框架上建立质量方案与性能优化方案，所以研发模式极其重要，是当前业务背景下一个大前端长期技术建设的主路线。
说了那么多，常见的建设是怎样的呢？ 关于MVP，MVC，MVVM的比较和实践很多，本人不再赘述。我们在从事真实开发的时候，MVP（以MVP为例）的拆分很难达到完全复用的级别，经常会出现过度设计的情况。这是由于交互场景的特色决定的，业务上每个页面有其自己的特色与用户心智的诉求，所以经常出现信息的展示完全不同，复用几乎不存在可能性。
所以该怎么办？ 我们抛开现有的架构设计，回到事情的本身，开发一个页面（主要是在CS架构下，部分场景下还存在通过后端推送变更数据，本质也是一样，只是数据获取的方式从主动变成被动），运行时是以下几个步骤
- 客户端编写抽象页面布局，里面主要是单一view，列表,列表里面的各个item
- 约定后端接口字段
- 从服务端获取约定数据
- 将数据转换到自己的UImodel上
- 讲UImodel和自己编写的UI进行映射
- UI交互后，变更UImodel刷新UI，弹窗，跳转，或者其他交互效果
针对目前的开发过程，我们的目标是提升研发效能。那什么是研发效能？我摘抄一段话：团队能够持续地为用户产生有效价值的效率，包括有效性（Effectiveness）、效率（Efficiency）和可持续性（Sustainability）三个方面。简单来说，就是低成本高效率完成可持续迭代的软件产品。考虑提效降本与高可迭代相结合，入手的思路比较简单，在频繁的迭代中，能够高复用与高扩展，这个思路简直是废话，但是无比正确。核心在于复用什么和扩展什么没。
起个引子，大家应该知道汽车工业的发展吧，汽车进入工业化之后，最关键的一次飞跃就是福特汽车的流水线模式，通过零配件标准化与流水线的建设，极大的降低了生产成本，提升生产效率。软件研发本身也在从手工化走向工业化的进程中，所以可以借鉴汽车生产的经验。是不是可以根据研发过程建立流水线，将流水线中的每一步抽象出一个工作切面，流水线承载的越多，上层暴露的切面越简单，我们的研发效能是不是越高，是不是可以实现我们的目标。
结合刚才说的开发步骤，核心思路是，将所有研发过程进行拆分，部分沉淀在研发流水线中，部分开放出来。那么沉淀的是什么，开放的是什么？
在这里，我们从自己的交互特色出发，一般的前台页面实际上有两种要素组成，第一种是以最小业务单元的view，由于其一般还包含着数据与逻辑的管理，综合起来叫做组建，比如搜索结果页面的一个商品展示组件，第二种是特殊的容器组件，他里面可以包含多种组件，组件存在的展示顺序关系，比如从上到下或者从左到右，例如一个列表，或者像搜索结果页面的筛选区域。这里本身存在一种协议关系，A组件应该放到X容器组件中，是不是就可以这么设计，页面owner设计容器组建，里面的组件开放出来任何人都可以开发，由于基础能力沉淀，上层功能基本组件化，基本就实现了降本。
为了实现这个目标，首先是一个后端搭建系统，搭建实现的是页面里面的组件构成与组件UI关系，组件包括，组件UI映射前台什么UI，绑定了什么接口（或者映射了数据接口的什么字段），组件的AB关系，打点协议，以及部分组件的UI描述关系。其次是后端的数据接口转换系统，传统的数据是直传过来的，客户端进行解析与映射UI，这里直接在后端构建这层关系，直接在后端实现原始model向UI组件model的转化，这样复杂的客户端逻辑，既可以在服务端实现，服务端通过函数化的开发，将这种转化实现成函数化的开发，降低了转化的问题。最后是前台页面代码变化，页面是一个协议解析器，解析的是搭建系统的UI，以及将转化后的数据直接绑定到UI上，同时实现打点。
通过这种方式基本就是可以将页面开发变成了某个区块的组件开发，团队的人力就可以相对自由部署。基于这种流水线线开发，8成的开发都可以低成本开发，2成的开发是页面框架的调整。同时由于底层变化的较少，且由于容易出错的地方全部收敛，质量问题也顺势解决。性能问题也可通过框架底层进行优化。目前我们看到，前端也开始利用react进行组件化开发，naitve也出现了一些动态化dsl渲染，进一步加强了这种模式。kotlin compose，swiftUI的出现，均是对组件开发的模式的扩展。那么像flutter出现，也会从最开始的渲染特色走向软件工程的研发，我估计也会走到这种模式里面。
当然还存在特色化的业务也可以通过沉淀协议化的接口以及业务层的事件传递机制实现组件的单元化开发。
那么再向前走的话，路在哪里，第一种的可能性是组件渲染模式的统一，尤其是dsl是否可以统一，多端一致渲染。另一种是页面框架的标准化，一些常见的底部多tab，顶部多tab，以及手指纵向滑动的组件标准化后，是不是可以通过搭建，实现页面框架。常见的页面就能通过配置化开发，不是非常复杂的组件可以通过统一dsl开发，帮助业务实现快速开发。
