软件的复杂度
- S：在学习和实践“软件的复杂度”时，需要建立统一的概念和问题边界。
- C：相关概念、实现机制和工程取舍容易混在一起，导致只记住结论而无法判断适用条件。
- Q：“软件的复杂度”要解决什么问题？它的核心抽象、工作机制和边界分别是什么？
- A：本文围绕“软件的复杂度”整理核心概念、关键机制和工程实践，并明确其适用边界。
S 业务成功驱动软件规模持续增长 C 偶然复杂度随团队扩大和赶工不断膨胀，侵蚀开发效率 Q 如何区分并控制软件的复杂度？ A 识别本质 vs 偶然复杂，通过统一技术栈、一致命名与抽象、减少临时补丁来遏制偶然复杂度
No Silver Bullet — Essence and Accident in Software Engineering https://worrydream.com/refs/Brooks_1986_-_No_Silver_Bullet.pdf
软件复杂 = 本质复杂 + 偶然复杂
本质复杂来自业务本身，不可消弭；
偶然复杂来自实现方案和技术选择，常被组织和工程实践放大。
业务成功 -> 本质复杂度⬆ -> 支持业务，偶然复杂度⬆
团队规模扩大，更容易制造偶然复杂度（堆高认知负担）：
- 赶上线的 flag/if，而不是调整设计
- 统一技术栈里面混入个人喜好的异构技术
- 同一领域在不同模块使用不同命名
如何控制复杂度(历史代码、技术选型、组织协作)：统一技术栈、强化命名与抽象一致性、减少临时补丁式开发、重视问题空间理解
复杂度管理的关键，不只是把系统拆成模块，而是让团队能够建立、共享、验证和延续对系统的理论。
[[1712851200-APOSD|]]: 复杂性不能凭空消失，它只能被合适的结构承载，并被放置在合适的位置。软件工程的任务，就是设计这些结构和位置。
评论