界面的本质及根本提效途径

前端开发的「术」第二篇

界面的本质
—— 色值的点阵。

我们通常说的界面，其实是时间轴上的一系列界面，还有，界面背后一系列用于持久化数据的动作。

所以描述一个界面的复杂在于其信息量大，这是其 「本质复杂」—— 不管如何变化描述方式，传递的信息始终都要这么多。

先回顾下，描述 web 界面的过程中，不必要复杂如何被逐步消除，并逼近本质复杂。

消除不必要复杂

利用变化的连续性

利用变化的连续性，这一额外信息。

base image + 变动。

除了第一次提供完整的界面信息，之后只需要提供相对上个界面如何变动即可。

利用模型简化高频场景

利用 Web 多是用于展示文本内容的特点，像素的点阵描述可以转化为：「盒描述」+ 字体库 + 排版规则。

这里细说下盒描述：盒可以用一个对象建模，来说明其各个属性，但与一个盒相关的属性实在太多，急需一个更方便人看和理解的书写方式，来替换对象的写法。

这就是标记语言 HTML —— 以标签的方式写深层嵌套的对象。

如此，便很容易理解 JSX 之类语法的出现。

从这得到的启发：

可以把信息的描述，转化为：元信息（比如上面的盒描述）+ 规则，抽象程度最高的规则，即模型。

规则通过具体的场景提炼，这样使用时只需要提供元信息即可，相比之前的完整信息，复杂度大大下降。

仔细思考上面的过程，描述的复杂度越来越低的原因在于：

* 充分利用了具体场景的信息，把它固化为规则，如果挖掘不到场景信息，复杂度是降不下来的。

也从侧面说明了，

为通用场景设计的方案，必然用法复杂。细化方案应用场景，是降低复杂的绝佳途径。

理论上，任何声称全场景无代码方案，要么不可行，要么和写代码的复杂度相差无几。

根本提效途径

「 RPC 几十年前就已经提出，核心至今没有发生变化，以至于我这十几年前的开发，现在依然能在这分享 RPC」，在一次内部开发大会上听到，印象很深。

之所以每个人生来善于钻研、追求本质，因为「永恒」的渴望。只有抓住了不变的部分，才能抵抗时间的洪流。

深入分析界面开发的演变，启发我们如何提效。

善用约定

一个有意思的段子：据说 80% 的人仅仅使用 office 不到 20% 的功能。

约定以及默认配置（模板），在减少模型输入方面，效果惊人。

所以，提供一个适应场景的默认配置，用户仅需要描述相对默认配置的变动即可。

一致性

一致性，是实现自动化和共享的基础。

一致性表现在代码规范，接口设计 - 小到函数大到 HTTP API。

只有规范和可复用的代码才是资产，否则都是负债。

一个函数、组件、功能，如果总要付出额外的开发成本，才能做到可复用，那说明需要做出改变，尤其研发流程、周边工具。

开发可被共享和复用的组件，对开发能力和时间的要求，应该要做到，和开发一次性组件接近。

如果要积累代码资产，就要尽快建立这种机制，让每个人在不自觉中，都让下一个需求开发更快。

组件共享机制很重要

在方案设计阶段，要额外关注具备『时间复利』的功能。

leader 的这一教导，使我受益匪浅。

组件共享机制的建立，随时间的价值是指数级别的。

随着系统的不断发展，共享组件的积累。也许今天要通过写代码实现的功能，未来通过（可视化）配置即可完成。

所以，组件共享机制的存在，随着系统持续发展，开发成本才不会增长的太快。

组件建设思路

首先建立组件共享机制。

共享的关键是约定不同类型组件的 interface。组件开发，接口设计先行，用之后的复用场景（放置在哪些父组件下），来设计接口。

比如，数据输入类的组件，要遵循 value onChange，这样才能被 form-item/form 组件包裹，获得校验等增强逻辑。

如果不遵循这个约定，或者接口没有一致性，开发的基本是一次性组件，共享和复用很难做。

管理端低代码，对开发最大的意义也是这个，约定了共享组件的 interface，属性、事件、方法怎样暴露出来。

这样每个人的写的组件，都可以成为组件市场的一部分。

总结

通过分析界面的本质，引出开发提效的一些途径。实践不止，这些途径也不会静止不变。

要点：

• 界面的本质复杂是屏幕上的像素信息量；
• 充分利用背景信息进行推测 + 建立模型，可以减少输入，提高效率；
• 一致性，是建立规则、抽象模型，自动化的前提。