vsc提示只有一行_企业软件的正确模式只有服务没有产品，持续交付效率决定成败...

近日偶读 @徐飞 同志的 《从前端角度看企业软件的研发过程》（以下称前文），难得有了写兴，这里留个记录。阅读提示：文略不对题 。

前文提到了软件服务企业的核心竞争力问题，并给出了关键答案：业务抽象能力。这也是我长期思考得出的结论。但是“业务抽象”这个词不够准确，各个从业者的解读甚至完全不同。对销售人员而言就是粗略的几个模块名称；在项目经理眼中就是需求文档、流程图；在业务开发人员看来是API、SPI；对平台研发者来说就是是中间件、微服务。

我的解读是，从具体的业务描述到软件成品的持续交付效率（这个跨度有点大，但是如果你理解前文的内涵，就不是问题）。特意突出“具体”二字是因为研发者不可能根据抽象描述去杜撰业务细节，抽象其实属于内部思考和技术处理环节。严格来说，业务描述必须具体，技术描述才需要抽象乃至隐藏。我也强调了“持续”，也就是前文末尾所说的“升级自己 3-5 年前给客户交付的系统”。我认为，企业软件的正确交付模式，只有服务、没有产品。因为业务需求是持续演变的，而产品只能定型交付，唯有持续的研发服务才能满足企业的真实需求。

然而，企业软件行业几十年的发展，实质上只见产品，没有服务。传统软件企业提供的二次开发是服务么？不是！它是为了销售产品而做的买一赠一式妥协，好比空调厂商的上门安装。软件外包公司提供的是服务么？不是！它提供的是类似新房装修的产品，装完概不负责。SaaS虽然号称“服务”，本质上却是比产品还要产品化的一种模式，连二次开发都省了，挟互联网之名要求企业迁就自己的产品。问题的根本原因是“持续研发服务”的成本太高，甚至高过首次开发。只有不差钱的金融、电信行业和不怕烧钱的互联网企业可以在内部维持这样的持续研发。

这是关于生产力与生产关系的矛盾的老故事。依靠工程师开发软件的生产力决定了软件只能以产品模式（包括外包、SaaS）交付，导致企业客户不满意，付费意愿差，行业利润低到留不住合格的研发人员，进而影响软件企业进一步发展。打破这种恶性循环的唯一出路，是让软件制造软件，提高生产力的等级。正如手工制造纺织机、蒸汽机不是工业，用机床制造各种机器才是工业时代的标志；信息时代的标志应该是某种“软件机床”。

近两年颇有些起势的低代码（零代码）平台正式基于这样的出发点而生。然而，考察下来却发现，它们的方法论都错了。最根本的问题是，把可视化开发当成了低代码开发的根基，这更像是不懂开发的老板自嗨式的想法。图形化开发有其适用的场景（暂不多论）。做过开发的人都知道，对于绝大多数业务逻辑而言，用代码表达比编辑图形效率高的两个数量级。有些平台宣称要让业务人员不再依赖技术人员，自己配置配置就可以开发软件。这更是商业上的大谬，本来花钱能解决的事，现在让业务人员自己做系统？！业务人员根本没有意愿做任何形式的开发，无论多么可视化、多么方便。很多人连缕清需求和逻辑都很困难（没有贬低的意思，术业有专攻，顶级的厨师也搞不懂自己每天用的厨具要怎么制造）。

低代码开发有一个绕不开的问题，就是开发能力的完备性。就是说，凡是传统手工开发能够实现的业务需求都能通过平台实现。我曾经认为没有必要执着于这个问题，然而当考虑“持续服务”的时候，则必须有一个恰当的回答。如果不能确保下次提出的新需求可以被实现，谁敢依赖这个平台做软件？如果是平台+手工混合开发，究竟是提升效率还是造成更多负担？现有的平台似乎都在回避这个问题，把企业软件归纳为表单+流程+报表。这显然过于简化了，做一些独立的小软件应该没问题，对于稍微严肃而复杂的需求则难堪大用。更遗憾的是，这一套方案根本就是二十年前的旧酒换上了Web和App的新瓶，没有任何本质的进步。

低代码平台们的自我宣传往往毫不负责的夸大其适用范围，让有意向的企业颇有质疑而又无从验证，只能找各种具体而琐碎的功能点提问，很容易被忽悠。对于这样的企业，我给你们一个武器，叫 Michael Test。你只要问对方，现在有一家新成立的银行，我能不能用这个平台开发该银行的所有系统，让这个银行顺利开业，如果不能，也请列出能做的范围。

最后，忘掉低代码/零代码这些时髦词汇，什么才是“软件机床”的根基？我认为正是前文说的“业务抽象能力”。不过我还是要换一个提法，叫“业务描述能力”。这个描述不必执着于可视化，重要的是精确而简洁、只与业务相关，并具有良好的完备性，“机床”依据输入的业务描述自动产生软件。这才是提高持续交付效率的出路。