树袋熊|低代码开发平台到底是“秀”还是“坑”？
随着零代码/低代码开发平台的普及与发展 ， 在主流的吹捧声音之外 ， 最近也听到一些反对的声音 ， 认为零代码/低代码开发平台是个伪命题 。 根据技术发展周期 ， 这恰恰说明这个领域的发展趋于理性了 ， 大家回归到商业本质去思考值不值得的问题 。
今天我试着从几个方面来阐述一下 ， 低代码开发平台这个赛道对于用户和厂商来说 ， 到底是“秀”还是“坑” 。
低代码的秀一提到低代码开发平台是趋势和潮流的时候 ， 我们往往喜欢在一个宏观的叙事背景下展开讨论 ， 比如技术的变革、人力成本的上升、市场环境的快速变化等 ， 但具体到每个企业的选择 ， 核心只有五个字：成本与效率 。 对于客户而言 ， 低代码开发平台给他们带来的好处是显而易见的：
首先是平台可灵活组装 ， 应用具备很大的柔性 ， 这意味着企业可以根据自身的特点量身打造信息化系统 ， 用于支撑其差异化经营模式以获得竞争优势 。 这往往也是低代码开发平台最具吸引力的一个卖点 。
然后是开发和维护过程自主可控 ， 无需依赖专业开发者 ， 低代码开发平台把开发技能变得公民化 ， 只要懂业务的人学习平台的开发模式就能够完成应用搭建 ， 而这个学习还是低门槛的 。
最后就是经济实惠 ， 用标准产品的价格获得了差异化的体验 。
对于厂商来说 ， 客户的需求就是我们的导向啊 ， 既然低代码开发平台对客户的价值这么大 ， 那这个就是好东西 ， 没有条件创造条件也要上 ， 蹭一下也是好的 。 除了客户价值 ， 低代码开发平台的出现还为厂商描绘了两个令人着迷的图景：
【树袋熊|低代码开发平台到底是“秀”还是“坑”？】一是市场容量足够的大 。 绝大部分有协同管理需求的客户 ， 甭管是OA的、CRM的、项目管理的 ， 还是各种涉及核心业务的协作需求 ， 都在低代码开发平台的射程范围内 ， 比单一市场一下大了好几倍 。
二是让厂商具备了解决方案横向扩展的基础 。 低代码开发平台上的应用是基于统一的标准、统一的运行时 ， 天然具备跨企业迁移能力 。 意味着基于平台的应用设计得足够通用 ， 是有很大的可能成为一个既通用又可灵活调整的解决方案 ， 复制成本极低 ， 而且所有的解决方案天然互通 。 当然前提是解决方案的设计要足够有行业针对性 ， 用这种方式做通用领域的应用是上不了台面的 。
种种好处确实存在且显而易见 ， 所以才让微软、谷歌这些巨头也亲自下场 ， 然而低代码开发平台也有无法回避的问题 。
低代码的坑对客户而言最大的问题在于难以获得高质量的服务 ， 这对于动手能力差的用户尤其不友好 。 无论是自己实施还是委托实施 ， 应用开发完成使用起来只是第一步 ， 后续的迭代和维护工作量也不容忽视 。 标准的应用产品有标准化服务流程、帮助手册、培训服务、FQA等 ， 都是经过打磨考验的 。 但基于低代码开发平台低成本实施的应用 ， 其差异化决定配套的服务无法产品化、规模化 ， 只能由具体的人来提供 ， 这种不经济的模式注定客户要为高质量服务额外付费 ， 要么就自给自足 。
对厂商而言“坑”可能更大一些 ， 这个市场可能很难规模化 ， 因为规模化和差异化存在难以调和的矛盾 。 一方面差异化意味着个性化 ， 而个性化就是无法规模化的 ， 另一方面即使低代码开发平台通过预置件实现了差异化和规模化 ， 主打的最大卖点量身定制 ， 需要依赖差异化的服务成本才能实现 ， 售前售后的服务成本都很高 。
除了市场规模化问题 ， 产品也有理论上限 ， 低代码开发平台的维护成本和成熟度/复杂度曲线是一条U型线 ， 随着成熟度/复杂度提升 ， 维护成本先下降再上升 。
举个例子 ， 在表达式引擎（有的叫公式编辑器）研发中 ， 最开始只是为表单模型而设计 ， 随着迭代深入会发现这个引擎在很多地方都能用 ， 内容构建、触发计算都能使用 。 但随着边界的扩展 ， 要不断地增加获取的上下文、要支持纵向计算、要支持SQL模式等 ， 与不同模型构建场景可能还会冲突 ， 不得不做一些妥协 。 另外 ， 指数级增长的组合数量也会带来一定程度的混沌性 。
推荐阅读
- 空心|记 Arthas 实现一次 CPU 排查与代码热更新
- 路飞写代码|59连问仍需联合调查，贝索斯的亚马逊被针对？，百亿订单成泡影
- 树袋熊|中国科学家发布亿级神经元类脑计算机
- 薄情先生|你所需要知道的代码整洁之道
- 树袋熊|这个技术，让我放弃了戴套
- 程序员|程序员：代码全部替换成中文，你能接受吗？
- 树袋熊|Epic宣称自己在革命，再次要求法院让苹果解禁《堡垒之夜》
- 小镇的夕阳|修改硬盘MBR代码，用1024字节实现一个操作系统启动管理器
- 星球狂想战队|推荐一款脚手架工具plop，利用模板批量生成代码，省时省力
- 苏眠月|DDD as Code：如何用代码诠释领域驱动设计？