徐飞
前端开发话题下的优秀答主
已关注
385 人赞同了该文章
这段时间，跟不少朋友讨论过有关“可视搭建”、“低代码”、“零代码”相关的一些话题，也当面解答过一些问题，感觉有必要把一些观点写出来。
搭建系统的实质
一个基于搭建的想要解决提效问题的平台，需要至少能明确回答几个问题：
- 软件系统的开发效率消耗在哪些环节，原因分别是什么？
- 当前所面向行业的人员状况分别是怎样的，软件系统有哪些类别？
- 为了提升效率，策略可能有哪些，分别是从什么角度解决，有可能带来什么新问题？
- 未来的产品规划里，你期望的平台使用角色是哪些，分别如何参与的？
- 出现未知领域的新业务产品，平台可以如何去支撑？
- 整个这个体系，更长远的发展思路是什么？
业务的复杂度只会转移，是不会消失的。用代码表达，或者搭建系统表达，本质上只是改变了其组织形态，得到的管控方式有所差别，其业务实质是一样的。
所以，我们想要通过搭建系统来表达一个业务，其底层首先就要有对等于主流开发框架的架构，确保拥有完整表达业务需求的能力，然后才去做产品形态上的权衡。
如果我们面向某个行业，则不免需要与几种角色打交道：
- 业务专家
- 一般业务人员
- 有一定IT知识的人员
- 有专业开发技能的人员
所以，产品形态的设计，也是要考虑到他们的业务倾向和知识范畴。而其他的一些角色，尤其是设计师和前端开发人员，则应当尽可能在平台中消除他们的参与，把这两种角色提供的能力进行模块化，预先设计基于某个业务领域的交互集，然后由单一职责的研发人员来统一使用两种基建：
- 存储
- 交互
并且使用逻辑与规则把这些东西编排起来。
需要认识到，因为业务复杂度不灭，实际上所有的业务复杂度都聚集在单一职责的研发人员身上了，所以如果从零开始建立一个业务系统，唯一感受不到提效的会是这个角色，这是一种必然。对他们的提效，需要在业务差异化定制的时候，由对业务复用的方法论去体现。
业务软件的定制化
在业务软件领域，通常会面临定制化问题，除了少数功能极其单一的软件，一般都会存在差异化需求。绝大部分业务软件会被这个问题困扰。
基于代码分支实现的差异化需求管理，是一种比较艰难的方式，因为单一的业务功能，往往其变更贯穿前后端，涉及代码中的多个位置，而且这些代码中的实现，往往与其他功能也有关。所以本质问题就是，功能点不是独立隔离的，导致要从某家客户的版本迁移给另外一家客户，是一件比较难操作的事情。
目前，大部分主流行业软件提供商都会提供各种维度的定制能力，但是它们一般有一个共性：围绕自身的业务领域。这种可定制能力，可以认为就是：低代码。
低代码的含义在两个方面：
- 可以通过代码来扩展业务能力
- 比直接写代码的那种方式代码要少一些
结合我们在上一节提到的，一种可搭建平台的底层实质上是一种框架：
- 写代码扩展业务能力，是基于框架的扩展点，并且这些扩展可以被管理起来
- 代码少一些，是因为框架额外提供了一些能力
纵观整个应用开发体系，我们可以发现，最适合低代码发挥的前提是：
- 针对一个特定业务领域，已经存在完整的标准化业务实现了
- 交互集也已经齐备
然后，可以修改规则，添加校验，编排现有的动作，调整视图的结构和布局，并补齐剩余的其他细节修改。
所以，从这个角度，我们可以认识到：
低代码的主要适用场景是解决相同业务领域下的差异化问题的。尽管可能存在这样的能力，但是我们并不期望某种业务从零开始基于低代码搭建整个业务，而是期望定制化团队使用这样的方式去进行小规模定制，并且把这种定制的差异化，隔离在其自身的作用域中，不对其他租户或者客户产生影响。
业务软件的个性化
定制好了以后，出厂交付了的业务软件需要很强的个性化能力吗？
这个问题很有意思。传统观念，这类软件用来办公的，个性化的价值很小，但是我个人觉得这个问题是可以探讨的。
疫情期间，大家都会去戴口罩，口罩应该长什么样子呢？就是通常大家所能想象的形态，最多是形状和颜色有差异。人们对业务系统的认知通常也是差不多，就是大面积的表格表单，风格稍有差别而已。
但是有一次，我看到一位之前的女同事，她发了一张非常好看的口罩照片，这照片里的口罩是蕾丝的、绣花的，配合她靓丽的面容，简直如虎添翼（划掉，重新想个词！）。
很多年前，我们上一代人的办公桌是什么样子呢？木制，偏棕色，有的会盖一块玻璃，上面放着电话机，纸笔，有的比较雅致的，会放一盆水仙花。
那么，现在，大家的办公桌又如何呢？已经有很多人个性化装扮了自己的桌面了，比如很多人桌面放着玩偶（据说叫做手办？这个我不太懂，用错词了大家体谅下。。。），有的放着乐高积木搭建的某种建筑，有的放着其他形式的装饰。
所以说，会不会是我们不需要定制业务软件，而是因为之前的可定制能力限制了大家呢？
通常的业务系统中，都会给用户留一定的个性化空间，最典型的就是工作台。通过这个去组织自己的工作习惯，但大部分系统实际上只是把它当作功能入口来使用，没有真正地做好这块，因为把每种业务模块都提供可集成单元的代价较大。
如果我们抛开这种固有的看法，把视野拓宽到整个应用中的一切业务视图，如果都尽可能地赋予用户自由组合与调整的能力，对使用效率的提升一定会很巨大。
这样，个性化不再局限于风格与主题的定制，而是真正体现到了业务表现形态的差异化和高效化。
所以，从这个角度，我们可以认识到：
无代码的主要使用场景是在业务齐备的情况下，不更改业务语义，解决个性化需求。每个用户，可以定制自己的工作台，调整业务界面的布局形态，设定某功能的搜索偏好，调整表格和表单种字段的填写和展示状况，等等。
小结
综上，我们可以发现，不管哪种形态，都只是相同底层约束之上，面向不同使用群体的一种产品抽象而已。它们从不矛盾，而是互补的。甚至也可以从另外一个角度看待，提供一种从轻度差异化到重度差异化定制的产品升级路线，使得每个层面的客户都可以得到适合自己层次的需求定制度。
编辑于 2020-07-05 22:48