第二章 传统开发模式在规模化后的核心瓶颈
在高级语言诞生后的相当长一段时间内，行业普遍认为，只要语言不断演进、类库不断完善，软件开发效率就可以持续线性提升。然而，当企业软件进入中大型规模，并在真实组织环境中长期运行后，这一判断开始失效。问题并不主要出在语言本身，而是出在传统开发模式与企业软件现实约束之间的结构性错位。
2.1 企业软件开发的真实起点：小团队、不稳定需求
与互联网产品不同，大多数企业软件项目并非从'大规模系统'起步，而是从小团队、小范围需求开始演进的。一个典型的企业软件项目，往往具有以下特征：
- 单个项目的开发人员规模较小，常见在 3-5 人以内：一个制造企业的生产排程系统，可能只有 3 名开发者，甚至没有专职的产品经理
- 需求来源复杂，往往来自业务部门的阶段性诉求：财务部门要求增加多币种支持，采购部门要求增加供应商评级，这些需求在对应系统的立项之初，往往没有统筹规划
- 需求本身不稳定，存在频繁调整、回滚和例外情况：一条审批规则可能因为组织架构调整而每季度修改一次
- 软件生命周期长，项目交付只是开始而非结束：许多企业软件会运行 5-10 年，期间经历数十次甚至上百次的需求变更
在这种背景下，传统高级语言开发模式在初期通常'看起来一切正常'。开发者可以通过直接编码的方式快速满足需求，组件和框架也能在一定程度上提升效率。但随着时间推移，系统规模扩大，问题开始显现。
2.2 组件化与框架化的效率上限
组件化和框架化，是高级语言时代应对复杂度增长的两种核心手段。它们通过复用代码和架构经验，在早期确实显著提升了开发效率。然而，这种提升并非无限。组件与框架解决的是'写不写得快'的问题，而不是'能不能长期管控'的问题。
2.2.1 组件的版本控制复杂度高
当系统中组件数量不断增加、依赖关系逐渐复杂时，开发者需要投入大量精力去理解组件边界、调用方式和版本兼容性。例如，一个看似简单的日期选择器组件，可能依赖了 moment.js 做日期处理，依赖了 popper.js 做弹出定位，依赖了某个图标库做 UI 渲染。组件越多，组合复杂度越高，整体系统反而更难以掌控。更麻烦的是，当某个底层依赖需要升级以修复安全漏洞时，可能会引发连锁反应，导致数十个组件需要同步更新。
图：一个小型编码开发项目依赖的组件与频繁更新版本
2.2.2 框架的约束过于'软性'
框架在规范结构方面发挥了更大的作用，但它的价值同样存在边界。框架能够约束'系统长什么样'（例如 MVC 架构规定了 Model、View、Controller 的分层），却很难约束'业务逻辑应该如何表达'。在企业软件中，大量复杂性正是来源于业务规则本身——比如'采购金额超过 10 万需要总经理审批，但 IT 类采购无论金额都需要 CTO 审批，除非是紧急采购且提前在钉钉群中知会'。这些规则最终仍然以命令式代码的形式分散在各个模块中，框架对此无能为力。
当团队规模较小、人员相对稳定时，这种复杂性尚可通过经验和默契来消化；一旦进入多人协作、长期演进阶段，问题便会集中爆发，尤其是当出现人员变动时。
2.3 '千人千面'的代码与规范化困境
在传统开发模式下，即便使用同一语言、同一框架，不同开发人员对需求的理解、对平台机制的掌握程度、对编码风格的偏好，都会直接反映在代码中。以一个常见的场景为例：实现'订单金额根据客户 VIP 等级打折'的功能。开发者 A 的实现是过程式风格：
public double calculatePrice(Order order) {
double price = order.getAmount();
order.getCustomer().getVipLevel();
(vipLevel == ) {
price = price * ;
} (vipLevel == ) {
price = price * ;
} (vipLevel >= ) {
price = price * ;
}
price;
}
