前些天同事在会上做了个类比，大意是这样：Low 低代码就好似街边的大排档，也就是路边滩，适合做初期商业业务的快速验证，而传统代码就好似星级饭店，是验证商业模式后用比较大的投入建成的较长期的商业项目。 我们这里所说的低代码平台，特指微软的 Power Platform 平台。 可以参见我另外一些博文：

这个类比非常形象生动，也非常易于理解，同时也给了我很大的启发，把我的一些想法和思考记录一下。

TLDR; 个人有以下一些想法，摘要如下：

  • 可能代码编程更敏捷更象大排档
  • 低代码开发和代码开发耗费的人力可能差不多
  • 低代码开发投入的沉默成本可能并不会轻易舍弃
  • 软件不同于硬件投入，不能完全类比
  • 软件更应该比喻为一个生物体，是可以成长和更新的
  • 软件主要是个设计过程
  • 软件的生产过程，大概就是CI/CD的发布过程而已。
  • 软件成本和质量主要影响因素在设计过程，生产过程初期确定后成本就变得很小了，现代语言的编译和打包发布机制已经比较成熟了，生产质量也基本可以保持稳定一致。
  • 未来是全流程的服务，租用 iPhone 的思想，因此需要更好的模块化和组件化，更有利于回收和重用，这也是目前微服务 DDD 大行其道的原因之一吧！ 需求和技术无论怎么变化，总有些核心的领域建模和代码组件是不太会变化的，是可以随着需求和技术的变化而不断更新改进而重用的，而受低代码平台的限制和约束，可能就不具备这样的灵活性和优势了。

作为专业的程序员，我们应该是比较了解软件开发的详细过程的，对于软件开发的很多细节也深有体会，软件开发项目的整个生命周期实际是什么样的？我们需要更深入地思考一下。

有一个大家公认的事实是： 软件与硬件不同

软件通常是指无形的，通过编程开发出来的产品或服务，而硬件则是那些实体存在的产品，通常硬件产品是由一系列生产环节制造出来的，有些产品内部会附带着软件，共同形成大家喜欢的各类电子智能产品。

上面类比的大排档和星级饭店，也可以看成是某种意义上的硬件产品，不管是大排档还是星级饭店，都是需要实实在在的物质来组成，需要相应的成本资金来购买。

那么我们常说的软件产品，或者公司提供的一些应用服务又是由什么来组成的呢？是如何生产出来的呢？

这就要说到软件开发的全过程了，仔细思考这个过程，不管是硬件产品还是软件产品，它们的产生过程其实都可以分为两个部分： 设计和制造。 传统的硬件产品的设计和制造过程，相信大家都有一定的概念，设计过程是在图纸上或者电脑上的，而生产制造过程则是在工厂车间里。 那么软件产品的设计过程是哪些？ 制造过程又是哪些呢？

项目立项，架构设计，技术选型，需求收集、分析、梳理落实到用户故事，再拆解为开发任务，画出界面，写出代码，编译打包，完成测试后发布上线，这中间哪个环节是设计和生产制造的分界线呢？

仔细想想，应该是编译打包这一步吧，在此之前都是在设计，而这之后，就是软件的生产发布过程了，众所周知，软件是非常方便复制的，也就是说软件一旦生成了，它的复制成本非常低，不象硬件，每生产一个新的，都有相应的原材料消耗和较为繁杂的生产和装配过程。

可能最常出现的一个误区就是把程序员编程写代码这个过程潜意识地理解为软件的生产过程，比如码农的称号，比如早期的美工，比如用 PS 画出界面还可以称之为设计，而把这设计转换为 HTML、CSS 代码则好像就是早期前端的生产过程似的，也许早期这个界线确实有点模糊，而现如今前端技术的发展，已经远不是简单机械的代码劳动了，整个流程都更加工程化，所以以代码的编译为设计的结束和生产的开始是比较合理的。

由上所述，软件开发的过程实际上核心和主要部分其实是设计，而不是制造，那么软件行业曾经盛行的建筑工程的隐喻就是不准确的，早期软件开发项目的管理，有大量的实践是借鉴建筑或工业制造行业的管理实践的，由此而诞生的瀑布的软件开发模式，其根源误解就在于此，不能将软件开发的过程比拟为一个建筑的建造过程，甚至不能比拟为早期建筑图纸的绘制过程，毕竟图纸绘制也是画在实物的图纸上的，其修改成本也是相当高昂的，倒是可以等同于现今在电脑上设计图纸的过程，都是在虚拟的数字世界进行设计的活动。

那么，回到我们开头的话题，再仔细分析一下，似乎大排档的比喻就不再那么适合低代码软件开发了。

软件的价值，到底体现在哪里？个人认为有如下一些方面：

  • 易复用： 通过灵活的组合，可以一次编程设计，在多个应用场景发挥作用。这样投入的成本就可以产生多倍的价值。
  • 易修改： 可以根据不同的市场需要，做快速的修改和迭代，满足新的应用场景和市场需求，产生快速占领市场的价值。
  • 易复制： 这一点不用多说，如今的软件可被千千万万的人们下载使用，而并不需要更多的生产和制造，这是网络效应的价值。
  • 易配置： 通过方便的配置，可以灵活应对各种需求场景，从而产生灵活应变的价值。
  • 标准统一： 软件将传统行业的很多业务标准化，统一和简化了很多的业务规则等，从而产生了高效、统一的价值。

那么低代码软件开发平台（特指 Power Platform）是否切实落实了这些价值呢？

个人的使用体会是这样，Power Platform 本身的一些组件是符合上述这些价值的，也许因此微软有了不错的市场和销售，然而似乎用这个平台做出来的软件产品，就不再具备这些特质了。

  • 易复用： 较难自定义组件，自定义组件不能用在 Form 中， 不能灵活定义函数和方法， 大量重复冗余的代码。
  • 易修改： 由于重复和冗余的代码，较难维护和修改，再加上缺乏代码版本管理机制，多人协作也易出问题。
  • 易复制： 没问题。
  • 易配置： 微软提供了大量的权限角色、BU和平台配置选项，一方面有其方便的一面，但另一方面，又显得过于复杂，难以配置。
  • 标准统一： 业务和用户认证等方面可以标准统一，但整个平台是局限在微软的生态中的，很多方面并不是业界通用的标准。

那么更恰当的比喻应该是什么呢？

有时候我觉得象是玉雕艺术，我们都是玉雕的手艺人，玉雕的手艺有高低之分，虽然雕刻的内容都是蜻蜓，但创意、风格和最终效果可能有天壤之别，然而，玉雕毕竟是硬件，实实在在的艺术品，雕得不好就要报废，这跟设计软件还是有比较大的区别的。

我还觉得应该象是在设计一台生产其他机器的机器，企业的大多数软件都是生产力或者信息处理工具，最终产生价值还需要在具体的业务场景中使用才行，就象一些加工机械，加工的仅仅是一些零件，最终要拼凑成一台产品才能够运行和生产。然而这些比喻似乎都不很恰当。 软件就是软件，很大程度是虚拟的，修改的成本应该很低，复制使用的边际成本又非常低甚至为零，可以说大部分的精力应该是在设计研发阶段，而它的生产阶段相对来说是比较低廉的。

想来想去似乎开发软件很类似用 CAD 绘图，需要模块化，需要思考设计，很容易修改，可以模拟，可以通过另外一些模组或功能来测试和验证，可以不断地扩展自动化，可以不断地改善开发的工具等，然而，这已经变成很专业的领域，普通人就已经不太容易理解了，所以也不是一个好的比喻。

未来的产品会更加偏向于服务，随着技术的发展和更新，很多实践会成为可能，人们不需要购买具体的产品，而只需要购买需要的服务，比如说现在我们还是在购买手机，未来可能只需要购买订阅手机即可，最新型号的手机出来以后，我们可以很轻松地更换最新版本的手机，而不需要花费更多的资金来购买，这样厂家会长期为我们提供相应的手机服务。于是我们有了租用 iPhone 的服务了，按年付费即可。

低代码平台特别是 PowerApps 的特点就是快速搭建原型，方便做一些简单的 App 快速试验市场，如果要做成长线产品，那就还是传统编程实践比较合适，其实运用极限编程的敏捷实践进行的话，也不见得会慢多少，而且稳扎稳打，长期维护和扩展都可以保证。 同时也可以参考另一篇《在 Power Platform 上实践 JamStack 架构思想》考虑一种结合 Power Platform 和 React 等前端技术的解决方案

回到“大排档”的比喻，如果我们暂且就用这个比喻的话，也许使用高效的代码来进行软件开发，倒更象是一种可持续发展的大排档做法：

首先，我们使用代码开发，通常要选择一个技术路线、一个生态甚至一个框架等，这一点很类似我们要开一个大排档的选址、水电及物业等基础设施和服务。 而选择低代码平台，如 Power Platform，基本就选择了固定的技术路线，相当于入驻了某个商场的餐饮片区，很多基础设施是现成的，但也就强依赖于这个商场的设施质量、服务水平和发展前景了。

其次，我们使用代码开发，会尽量模块化和分层等，采用迭代演进的方式，一些核心模块会重点开发，考虑可读性、易维护性及扩展性等，从而达到比较长远地适应业务扩展和应变能力，这一点就类似我们开大排档的时候，会有一定的分工，一些核心的重点会相对重视，比如菜品原材料的采购、加工的卫生及菜品的口味等，可能会制定相应的标准和规范，选择一些易于清洗和维修的工具，选择一些可以长期使用，后期也可以适应变化和扩展的设施，随着大排档的发展和扩张，很多标准规范和工具设施是一直可以延用的。 而选择低代码平台，如 Power Platform， 很多模块和组件都只能使用商场提供的，标准和规范也必须遵循商场所规定的那些，随着自己业务的发展和变化，可能会越来越感觉到商场的限制所给予的阻碍，最终不得不做出需要搬离的决定，从成本角度、从业务发展角度、从客户角度都造成极大的损失。

最后，使用代码开发更象是自己装修开一个大排档，会有更高的自主性、可控性、灵活性，长远看来，比起这些，低代码更象是入驻商场，它所带来的一点点便利性，可能就不那么重要了。代码开发丰简由我，可以很快速上线一个 MVP 版本，解决最核心的问题，不断地迭代发展，随着业务的变化而灵活变化，反而低代码平台就会有较多的限制和约束，长远发展地看，很可能最初的一些投资成本就无法重用了，一旦需要技术转型就会损失惨重了。