代码|低代码产品的“逆熵”小败局( 二 )_

做过这种老旧系统重构改造的朋友应该知道，这个例子只是窥斑见豹。一个软件系统的迭代发展就是一个十分典型的“熵增”过程。
经过几年迭代早已和最初的规划相去甚远，还记得最早的微信，是一个只可以进行文字信息收发的IM软件，再看看今天的微信社交、内容分发、金融、电商、应用分发，已经是一个十足的“混沌系统”。
四、“逆熵”能不能行得通熵增，是系统发展的必然规律，与产品领域规划无关、与产品团队的能力无关、与企业战略规划无关。
因此，作为一个“搭建应用的应用”，低代码平台的建设规划需符合这一客观规律。
在各显神通的低代码市场，也的确有一些团队基于自己的业务背景，进行了通过“逆熵”将产品“低代码化”的尝试。
这些团队背景，基本毫无疑问是SaaS产品出身，做低代码的初衷也很简单，就是通过配置化，替代不同项目交付的重复编码工作。
Odoo、Zoho和OpenERP是这个赛道比较典型的代表。
Odoo在企业开源应用领域曾经风靡一时，起家于ERP领域，随着市场拓展陆续在ERP、CRM、PLM领域有了较强的产品积累，为了更灵活的拓展产品边界，提供给用户灵活的企业应用解决方案，Odoo给出了自己的“低代码”答卷。
依托自己建设多年的开源软件生态，Odoo在自己的低代码平台Odoo Studio中整合了丰富的功能模块，共用户来“拼装”新的应用。
不同于通用低代码平台将最小模块拆分到组件力度，Odoo的功能模块更像是一个个独立的应用，例如记账、用户管理、MRP、PLM、设备管理、质量管理等模块。

文章插图
对于用户，可以使用这些现有的应用拼装出一个自己所需的工作台，但如果现有的这些应用并不能满足你的需求，那么，则需要通过开源框架，用代码开发的形式编写一个新的应用模块。
同样，如果你需要让这些工作台上的应用协同起来，只能自己编写函数调用或者直接通过开源框架针对这些应用模块进行代码层面的二次开发。
从搭建应用的角度，Odoo应用市场的全部应用模块就是它的能力边界，Odoo Studio可以完成针对现有应用的拼装，但无法通过低代码拼装的形式产生一个全新的应用。
同样，某国产BPM厂商也交出了与Odoo类似的答卷。他们抽取自己BPM产品交付项目过程中一些常用的功能模块，以供之后进行复用，但由于本身提取的模块抽象程度不够，实际使用中不得不将“复用”变为“新增”，实际依然是新的一轮编码工作。
另外，由于模块不够标准，接口调用、数据连接用户很难上手，最终还是需要负责交付的工程师帮助用户完成。虽然售卖了低代码平台，但实际还是提供了SaaS交付级别的人力支撑。
这类产品普遍的方法论是基于已经成熟的SaaS系统，为了更灵活交付的目的，进行模块化的拆分，让一个已经成型的混沌系统有序化、标准化。
就像我们前文提到的，一个系统在演进迭代的过程中不断熵增，越来越混沌；而进行这种模块化的拆分就是一个“逆熵”的过程，在实际操作中会发现，由于模块与模块之间千丝万缕的联系，总是没有办法达到你想要的粒度，最终往往止步与一个完整的最小可用功能。
而对于一个工具，通用性直接取决于模块的抽象程度，粒度越小，就可以达到更高的抽象程度。
这类走“逆熵”路线的低代码工具，对于自己SaaS的交付场景，可能的确会有一些提效，但由于抽象程度不够，总是跳不出自己的领域，难以成为一个通用的低代码平台，最终也就成为了交付团队的低频工具。