对抗软件规模与复杂度的战争：救命、治病、养生（上篇）

记忆中的Google：外界视角与内部现实

作者回忆10年前参加软件工程会议时，Google的PPT第一页给他留下深刻印象。PPT画面展示了外界将Google视为科技巨头，而Google员工却认为公司步履艰难，体现了Google的谦虚态度和员工对软件研发本质的深刻理解。

软件研发的“手工业”本质

软件研发虽然已经从个人英雄主义时代进入群体协作时代，但仍然保留“手工业”的属性，依赖个体能力，规模小可以接受，规模大则难以为继。

规模与复杂度的挑战

随着团队和项目规模的增长，软件研发效率下降，出现规模与复杂度指数上升的问题。软件规模增长导致复杂度的更快增长，类似于人的身高与体重的关系。

软件复杂度的双重困扰

软件复杂度存在于系统和研发流程两个层面，大型软件系统的工作机制常常无人能彻底理解，且研发流程的每个简单改动都需要跨多个团队和工具协作。

软件的复杂性来源

软件系统难以一开始就设计完美，通常需要功能模块的迭代生长，伴随着复杂性的累积。软件架构师无法预知最终产品形态，与建筑架构师相比，软件架构更加动态和不确定。

控制软件复杂度的重要性

维护大型软件的核心在于控制复杂度，而不是减小，延缓复杂度的聚集速度。理解软件复杂度的本质至关重要。

软件复杂度的分类

软件复杂度包括问题域的业务复杂度、解决方案的复杂度以及软件本身的本质复杂度和随机复杂度，其中随机复杂度是由解决方案实现过程产生，需要避免。

随机复杂度的常见表现

随机复杂度通过许多实际案例体现，包括简单的workround、不同技术的混用、组件版本不一致等，这些都会导致系统的技术债务和架构腐化。

软件复杂度失控的原因

软件复杂度失控来源于业务的成功发展、时间积累未治理的随机复杂度、团队扩张带来的风格不统一等因素。

错误的应对方式

错误的应对软件复杂度增长的方式包括Deadline Driven Development和通过增加人手试图解决问题，这些方式可能引发更大的复杂度。

治疗和养生的探讨

关于软件复杂度的治疗和养生，作者计划在下一篇文章中详细阐述，并提供相应的解决策略。