前端开发的「术」第二篇
界面的本质 —— 色值的点阵。
我们通常说的界面，其实是时间轴上的一系列界面，还有，界面背后一系列用于持久化数据的动作。
所以描述一个界面的复杂在于其信息量大，这是其 「本质复杂」—— 不管如何变化描述方式，传递的信息始终都要这么多。
先回顾下，描述 web 界面的过程中，不必要复杂如何被逐步消除，并逼近本质复杂。
消除不必要复杂
利用变化的连续性
利用变化的连续性，这一额外信息。
base image 变动。
除了第一次提供完整的界面信息，之后只需要提供相对上个界面如何变动即可。
利用模型简化高频场景
利用 Web 多是用于展示文本内容的特点，像素的点阵描述可以转化为：「盒描述」 字体库 排版规则。
这里细说下盒描述：盒可以用一个对象建模，来说明其各个属性，但与一个盒相关的属性实在太多，急需一个更方便人看和理解的书写方式，来替换对象的写法。
这就是标记语言 HTML —— 以标签的方式写深层嵌套的对象。
如此，便很容易理解 JSX 之类语法的出现。
从这得到的启发：
可以把信息的描述，转化为：元信息（比如上面的盒描述） 规则，抽象程度最高的规则，即模型。
规则通过具体的场景提炼，这样使用时只需要提供元信息即可，相比之前的完整信息，复杂度大大下降。
仔细思考上面的过程，描述的复杂度越来越低的原因在于：
* 充分利用了具体场景的信息，把它固化为规则，如果挖掘不到场景信息，复杂度是降不下来的。
也从侧面说明了，
为通用场景设计的方案，必然用法复杂。细化方案应用场景，是降低复杂的绝佳途径。
理论上，任何声称全场景无代码方案，要么不可行，要么和写代码的复杂度相差无几。
根本提效途径
「 RPC 几十年前就已经提出，核心至今没有发生变化，以至于我这十几年前的开发，现在依然能在这分享 RPC」，在一次内部开发大会上听到，印象很深。
之所以每个人生来善于钻研、追求本质，因为「永恒」的渴望。只有抓住了不变的部分，才能抵抗时间的洪流。
深入分析界面开发的演变，启发我们如何提效。
善用约定
一个有意思的段子：据说 80% 的人仅仅使用 office 不到 20% 的功能。
约定以及默认配置（模板），在减少模型输入方面，效果惊人。
所以，提供一个适应场景的默认配置，用户仅需要描述相对默认配置的变动即可。
一致性
一致性，是实现自动化和共享的基础。
一致性表现在代码规范，接口设计 - 小到函数大到 HTTP API。
只有规范和可复用的代码才是资产，否则都是负债。
一个函数、组件、功能，如果总要付出额外的开发成本，才能做到可复用，那说明需要做出改变，尤其研发流程、周边工具。
开发可被共享和复用的组件，对开发能力和时间的要求，应该要做到，和开发一次性组件接近。
如果要积累代码资产，就要尽快建立这种机制，让每个人在不自觉中，都让下一个需求开发更快。
组件共享机制很重要
在方案设计阶段，要额外关注具备『时间复利』的功能。
leader 的这一教导，使我受益匪浅。
组件共享机制的建立，随时间的价值是指数级别的。
随着系统的不断发展，共享组件的积累。也许今天要通过写代码实现的功能，未来通过（可视化）配置即可完成。
所以，组件共享机制的存在，随着系统持续发展，开发成本才不会增长的太快。
组件建设思路
首先建立组件共享机制。
共享的关键是约定不同类型组件的 interface。组件开发，接口设计先行，用之后的复用场景（放置在哪些父组件下），来设计接口。
比如，数据输入类的组件，要遵循 value onChange，这样才能被 form-item/form 组件包裹，获得校验等增强逻辑。
如果不遵循这个约定，或者接口没有一致性，开发的基本是一次性组件，共享和复用很难做。
管理端低代码，对开发最大的意义也是这个，约定了共享组件的 interface，属性、事件、方法怎样暴露出来。
这样每个人的写的组件，都可以成为组件市场的一部分。
总结
通过分析界面的本质，引出开发提效的一些途径。实践不止，这些途径也不会静止不变。
要点：
- 界面的本质复杂是屏幕上的像素信息量；
- 充分利用背景信息进行推测 建立模型，可以减少输入，提高效率；
- 一致性，是建立规则、抽象模型，自动化的前提。
