前端领域模型，重构前端研发模式

烛象阿里云云栖号

作者 | 烛象

来源 | 钉钉前端团队

无论是小程序还是H5，前端(GUI编程)的展现形态的变化性一直是前端开发效率变革上最大的拦路虎，本文拟抽象一个新的概念「前端领域模型」，对研发模式进行重新思考，以探讨如何降低前端研发人力、提升开发体验为目标。

Part I 对规范/规则的论述

"无规范不成方圆"，规范的一致遵守能收敛噪音，达到一致性。在软件工程的领域，当规范演变成规则后，软件开发的持续交付会因为规则的遵守而得以保持垂直、正交，熵的变化也能有可见的收敛。

在前端开发的过程中，我把开发过程抽象成如下的公式:

1. 前端项目 = PageCompose(前端页面)

2. 前端页面 = ComponentCompose(Data(数据) + UI(展现) + Interaction(交互))

3. PageCompose ≈ Router(路由) Or Navigation(导航)

4. ComponentCompose ≈ Layout(布局编排)

目前市面上大部分的解决方案很多都是专注在其中某一个维度的方案解决，大致有以下几类:

UI 解决方案:

Ant-Design: 面向React的前端设计语言，UI规范的集大成者，用户遍布全球，Github近 60K star。

iView: 面向Vue的前端UI库，Github star近24K

Data 解决方案

Lodash: 老牌js工具库，用户遍布全球，Github近 45K star。

Rxjs: 异步流解决方案，Github近 22K star。

immer: immutable数据处理方案的后起之秀，Github近 17K star。

PageCompose 解决方案

React-Router: 面向React的路由方案，Github近 41K star。

整体的解决方案:

Umi：基于插件化的React应用解决方案。

Angular：大而全的H5应用解决方案。

以上列举的有名的框架或者库，是全球开发者用脑袋进行的投票，是值得研究和学习的典范。

作为以上解决方案的重度使用者，我非常强烈的感知到了规范和规则在软件开发过程中的巨大指引作用，这些规范和规则主要体现在如下几个点:

1.体验极佳的api设计: 明确的IO(入参和返回)。

2.明确的objective目标: 自律性极强，在某个解决方案领域做深做强。

3.单一的使用及设计规范: 单一的强规范约束让使用者"一处学会，遍地会用"，这是一款技术产品传播非常重要的点。

Part II 前端领域研发模式的探讨

"工欲善其事，必先利其器"，良好的研发模式是软件持续交付的重要保障。前端是软件开发中交付密度最高的场景，高频的变更和发布严重威胁着前端稳定性，因此"优秀"的研发模式对前端开发而言极其重要，在 John Ousterhout 的著作《A Philosophy of Software Design》提到软件设计的核心在于降低复杂性，这里面的我想说的"优秀"更多的也将专注在降低前端复杂性。

大部分前端的研发流程有着相似的分层结构:

现代前端开发已经有非常成熟的数据驱动(Data Driven Development)开发框架React/Vue、在UI组件库、函数库、网络库、异步处理、数据处理等领域也有非常多的优秀沉淀。然而，在生态如此繁盛的今天，前端开发在很多业务、很多公司依旧是最大的人力瓶颈，前端人效提升一直是令人头大的命题。

究其原因，笔者认为有以下几个急需攻克的难题:

1.UI层(前端界面)复用性极差: 前端UI代码大量采用VM(view + model)的方案，面向多样化的设计稿进行开发，代码差异化无法收敛。

2.Data层(数据处理)复用性极差: 服务端通信给前端的数据虽然已经是视图对象(view object)，但是仍旧带有鲜明的领域(Domain)属性，数据结构的差异化直接导致数据处理逻辑的复用性无法收敛。

举个例子。上图是非常经典的产品展示页面，然而这2个页面分属于不同的产品线，开发人员的物理隔离和UI上的些微差异性，直接导致彼此可复用的前端代码是0%，需要2个前端人员才能完成需求。

再深究下。以上前端代码复用度极差的后果，我们能归咎于产品、设计、运营等同学吗？或者说，产品、设计、运营同学，他们难道没有碰到类似的困扰？多次的重复工作，带来的效率问题始终是难以回避的问题。

对于前端开发来说，我想提出一个研发流程上的新概念: 前端领域模型来解决以上的问题。

Part III 前端领域模型的探讨

前端领域模型(FrontEnd Domain Model): 面向业务领域抽象的 UI 模型。

前端领域模型抽象出来后将会对整个研发流程进行一个重构，流程节点将会增加如下蓝色区域。

如上图，研发流程重构后，前端开发中的「业务UI」是面向「FDO」进行编程，把业务的个性化转嫁给了Adapter，从而达到「业务UI」复用(Low Code)的目的。

在实际开发中，前端同学需要做的就是「选择合适的业务UI模板」 -> 「实现(implement)对应的FDO」即可快速上线一个业务模块。

这种开发模式解决的最大的问题是软件开发的持续交付，通过将前端复杂度进行颗粒度的合理拆分，让每个需求迭代产生的复杂度，从指数级变成了线性。

Before: 业务迭代的复杂度 ≈ ViewModel的复杂度 = view复杂度 * Model复杂度

After: 业务迭代的复杂度 ≈ Model的复杂度 + View的复杂度

复杂度的降低带来的收益，不仅仅是前端效率的提升，更是前端稳定性的提升。

Part IV 进一步开放，甚至商业化？

对于大公司如腾讯、阿里、字节，开放平台在整个业务体系有着极高的战略意义。大量的生态ISV，如何开发出符合要求的应用，最直接的体现就是前端UI的一致性。

借助如上的研发流程创新，通过制定高质量的前端领域模型(FDO)规范，生态ISV可以较轻松的复用和遵守对应的UI开发规范，进行适当的改造即可快速开发出符合要求的应用，不仅仅是成本降低，更是效率的提升。

这里面的空间，可以想象下，对人力成本的解放有着重要的意义。

Part V 结语

本文是我在实际前端研发流程中，结合团队的实践进行的一些思考，算是一个抛砖引玉。

业内关于研发效率中的物料(Low Code)已经有非常多的讨论和实践。我尝试从另一个角度「前端领域模型」来看待研发流程的调优和标准化。通过规范化的研发分层将复杂度进行拆解，已达到高质量的持续交付。

关于引入的这个新概念 FDO 以及如何在团队落地，我们已经有一些实践，证明确实在研发效率上带来了较好的提升。当然，我觉得还可以有很明确的路径做得更好。

本文更多的偏一些概念的讨论，没有讲具体的实现，欢迎探讨。

更多精彩

识别二维码领取创业加油礼包

罗美琪和春波特的故事...

开源 1 年半star破 1.2 万的Dapr是如何在阿里落地的？

点个在看，让更多人看见

继续滑动看下一个