波仔
🕸️ 第二章 Web特有的架构
📄 一句话概括

四个词讲的是同一件事的三个层次：系统先要准、再要快，最后要省人力——SoR 与 SoE 是分工，低代码与无代码解决的是【谁来搭】。

📝 本节和前面几节的关系

第一章把 Web 的地图画完了：地址、服务器、浏览器、API、摆在哪儿、路怎么走。从这一章起往【后台】下潜——那台服务器上到底在跑什么。这一节先不碰技术细节，先讲为什么 Web 会变成今天这个样子：它一直在解决同一个老问题，改得太慢、改得太贵。

一、先分清两个词：SoR 与 SoE

这两个词原本是一对搭档，讲的是企业里两类系统的分工：一类管账，一类管脸。

账要准，脸要快——两边的脾气完全相反，所以不能按同一套办法管。教材把它们放在 Web 技术发展的开头，是因为 Web 这三十年的变化，几乎全发生在【脸】这一边。

这也解释了教材为什么用这一条来开第二章：后台的每一次技术更替，背后都是一次【谁改得起】的重新分配。

二、低代码与无代码：换谁来搭

分工讲完，接下来是第二个问题：这些系统由谁来搭。

传统做法的瓶颈很好懂：业务部门提需求，IT 部门排队做。这个队一排就是几个月，等做出来，需求已经变了。低代码与无代码想干的，就是把这个队拆掉——让懂业务的人自己动手。

低代码留给专业的人一个后门（复杂逻辑还能写代码补），无代码则把门焊死了，换来的是更简单的操作。代价也写在换算里：越简单，能做的事越窄。

三、动手 Demo：把四个词摊在两张表上

rows = [("记录的系统 SoR", "准", "ERP、会计、库存"),
        ("参与的系统 SoE", "快", "官网、App、客服")]
for name, key, sys_ in rows:
    print("%-16s %-4s %s" % (name, key, sys_))

实跑输出：

--------------------------------------------------------------------
D1  Web 技术的发展：SoR、SoE、低代码、无代码
--------------------------------------------------------------------
  教材这一条把四个词放在一起，是因为它们讲的是同一件事的四个阶段：
  系统先要【准】，再要【快】，最后要【省人力】。

  先分清前两个词——它们不是新旧关系，是分工关系：
  ----------------------------------------------------------------------------------------
  分类                  最看重什么    典型系统                多久变一次    出问题会怎样
  ----------------------------------------------------------------------------------------
  记录的系统 SoR        准            ERP、会计、库存         一年 2~4 次   账错、钱错
  参与的系统 SoE        快            官网、App、客服         一周甚至一天  用户跑了
  ----------------------------------------------------------------------------------------
  SoR 是公司的【账本】，SoE 是公司的【门面】。账本一年改两次，门面天天要改。
  两个词合起来回答了 Web 技术发展的方向：让门面改得更快、更便宜。

  再看后两个词——它们回答的是【谁来改】：
  ----------------------------------------------------------------------------------------
  分类                  谁来搭                  典型用途                  主要代价
  ----------------------------------------------------------------------------------------
  低代码                懂业务的人 + 少量代码   表单、审批、报表          复杂需求会撞天花板
  无代码                完全不写代码            问卷、简单官网            只能做标准的、简单的
  ----------------------------------------------------------------------------------------

  低代码这条路走得有多大？看这条曲线：
  ----------------------------------------------------------------------------------------
  年份        低代码开发技术市场        说明
  ----------------------------------------------------------------------------------------
  2020        132 亿美元                疫情前
  2022        225 亿美元                翻了一倍多
  2023        269 亿美元                比上年 +19.6%
  2024        319 亿美元                继续涨
  2026        445 亿美元                Gartner 预测值
  ----------------------------------------------------------------------------------------
  从 2020 年的 132 亿美元，到 2026 年预测的 445 亿美元：
    六年涨了 237%，平均每年 22.5%。

  更有意思的是【谁在用它】：
    新应用里用低代码/无代码做的比例：2021 年 40% 上下，2026 年 70~75%。
    用它的人里，80% 不在 IT 部门——这就是【公民开发者】这个词的由来。

  一句话带得走：SoR 保底、SoE 拉新，低代码与无代码把【拉新】那一半
  的成本压了下来；但它压的是【做出来】的成本，不是【想清楚】的成本。

读这个输出：先看两张表的【第一列】。SoR 那一栏举的例子全是公司内部的账，SoE 那一栏举的全是顾客能碰到的东西。这不是巧合——它决定了后面所有的取舍：账本出错要赔钱，门面出错只是丢人，但门面反应慢就直接丢客户。

四、这条线为什么和 Web 有关

回头看，Web 之所以能接住 SoE 这一半，靠的是它把【改】的成本压到了别的东西比不了的低位：不用给每个用户装客户端，改一次服务器、所有人第二天打开就是新版。

这个特性在 1-3 里已经见过一面：浏览器每次现取页面，所以服务器说了算。到了本章后半段（2-9 到 2-12）会看到，为了把这个【现取】做得更快更灵活，后台换过好几代做法。

五、⚠️ 2026 现状

教材写于 2024 年，这一条给的方向没有变，但有两处值得补：

第一，低代码的增速比教材预期还猛。2026 年新应用里用它做的比例已到七成上下，而且用它的人有八成不在 IT 部门——教材说的【公民开发者】已经从概念变成了常态。

第二，AI 接在了同一条延长线上。它压的还是那个【做出来】的成本，甚至压得更狠；但它压不动【想清楚要做什么】这一段——需求本身对不对，仍然只能由人回答。

30 秒实验

  1. 打开你常用的一个网站，找出三样东西：一个你只用来查信息的页面、一个你需要登录提交的页面、一个你看到就想立刻离开的页面。
  2. 给这三个页面各贴一个标签：它们更像【账本】（要准）还是【门面】（要快）？
  3. 最后想一件事：如果这个网站的团队预算被砍一半，你希望他们先砍哪一边？

常见误区

  1. 错误：低代码就是给不会写程序的人玩的玩具。——纠正：它已经是企业新建应用的主流方式。用它的人有八成不在 IT 部门，但这不等于它只能做玩具——真正被卡住的从来不是工具，是需求本身有没有被想清楚。
  2. 错误：SoR 过时了，现在都讲 SoE。——纠正：两者是分工，不是新老。没有账本，门面拿什么给用户看？真正该警惕的是两者之间的割裂——本课后面讲的 API（1-7）与前后端分离（2-10），本质都是在把这条缝补上。
  3. 错误：Web 技术发展就是界面越来越漂亮。——纠正：每一次大变化，改的都是【谁能改、多久能改完】。界面好看只是结果；背后是部署方式、前后端分界、程序启动方式的一次次重排——这正是本章后面十三条要一条条讲的。
  4. 错误：无代码比低代码先进，所以更好。——纠正：它们是同一条线上的两个刻度，越往无代码走，能做的事越窄。选哪个取决于你要做的东西有多复杂，而不是哪个听起来更新。先想清楚需求，再选刻度。
自测三问（点开对答案） 1. SoR 与 SoE 的根本区别是什么？用一句话说。 —— **SoR 要准，SoE 要快**。准的系统不能随便改，快的系统必须随时改。这个矛盾是这三十年技术演进的起点：所有后来出现的做法（低代码、前后端分离、云计算）都在做同一件事——**让【快】的那一半在不拖累【准】的那一半的前提下跑得更快**。 2. 为什么说低代码压的是【做出来】的成本，不是【想清楚】的成本？ —— 因为它省掉的是写代码、联调、部署这些环节。但**做什么、给谁做、做到什么程度算成功，这些判断工具替不了**。工具越快，做错的东西上线也越快——所以低代码时代真正稀缺的能力，反而变成了把需求想清楚。 3. 这一节的四个词，和后面 2-9 到 2-12 讲的脚本语言、CGI 有什么关系？ —— 前者讲**为什么**要变（准与快的分工、谁来搭），后者讲**怎么**变（服务器上的程序怎么跑起来）。**先有需求，才有技术选择**：正因为 SoE 这一半要改得快，后台才会从 CGI 那种每次重启程序的笨办法，换成一整套常驻的接口。

相关笔记