经典著作《软件设计的哲学》中文版 - 译者序 原

2016年，我在美国参加了一个Google内部的软件工程会议，会上Google的技术副总裁展示了一页令人难忘的PPT。这页PPT展示了一个具有戏剧性的对比：外人眼中的Google是高科技的象征，而Google 人眼中的Google却如同老牛拉车般步履蹒跚。这种对比一方面反映了Google的谦逊，另一方面也揭示了Google对于软件研发本质的深刻认知。

你可能很难想象，在软件行业如此发达的今天，软件研发本质上仍然属于“手工业”。尽管如今已经进入了群体协作的时代，大模型也带来了提升软件研发效能的潜在可能，但软件研发在很大程度上依然依赖个人的能力。当软件规模小的时候，手工业的方式尚可行，但随着规模的扩大，软件的复杂性也随之呈指数级上升。正如一个90 cm高的孩子体重约15 kg，而长到180 cm时体重可能达到75 kg，身高是原来的2倍，而体重却是原来的5倍。

软件的复杂性主要可以分为两个层面：软件系统层面的复杂性和软件研发流程层面的复杂性。

在软件系统层面，对于大型软件来讲，“when things work, nobody knows why”（当事情顺利进行时，没有人知道这是为什么）俨然已是常态。随着时间的推移，现在已经没有任何一个人能搞清楚系统到底是如何工作的，将来更不会有。

在软件研发流程层面，一个简单的改动，哪怕只涉及一行代码，也需要经历完整的流程，牵涉多个团队、多个工具体系的相互协作。可以说，对于大型软件来讲，复杂才是常态，不复杂反而不正常。

更糟糕的是，软件系统很难一开始就做出完美的设计，只有通过一个个功能模块衍生迭代，系统才会逐步成形，然后随着需求变多，再逐渐演进迭代。所以软件本质上是一点点“生长”出来的，其间伴随着复杂性的不断累积和增长。

对！你没有听错，软件是“生长”出来的，而不是设计出来的。

无论现在看起来多么复杂的软件系统，都要从第一行代码开始开发，都要从几个核心模块开始开发。这时架构只能是一个少量程序员可以维护的简单组成。你可能要问，那软件架构师是干什么的？他难道不是软件的设计者吗？软件架构师只能搭建一个“骨架”，至于最终的软件会长成什么样子，其实软件架构师一开始也很难知道。

软件架构和建筑架构有着巨大的差异。建筑图纸设计好，就可以估算出需要多少材料、需要多少人力，工期和进度基本就能确定了，而且设计变更往往发生在设计图纸阶段，也就是说，建筑架构的设计和生产活动是可以分开的；而软件的特殊性在于，“设计活动”与“制造活动”彼此交融，你中有我，我中有你，无法分开，软件架构只能在其实现过程中不断迭代，复杂性也在不断累积。

另外，建筑架构师不会轻易给一个盖好的高楼挖个地下室，但是软件架构师却经常干这样的事，并且总会有人对你说：“这个需求很简单，往地下多挖几米就行了。”这确实不复杂，但我们面临的真实场景往往是：没人敢保证挖了地下室之后原来的楼梯不会发生开裂甚至倒塌。

面对复杂性失控的挑战，软件研发组织必须采取合理的策略去控制软件的复杂性。注意，我这里讲的是控制，而不是降低。我们能做的只是延缓复杂性的聚集速度，但是无法完全杜绝复杂性的增长。

复杂性失控的原因有很多。最常见的错误方式是采用Deadline Driven Development，即用deadline（最后期限）来倒逼研发团队交付业务功能。这种做法虽然可以在短期内取得进展，但往往会牺牲软件的长期质量，导致大量随机复杂性的累积。长期来看，这种急功近利的做法会显著降低开发速度和质量。另一个常见的错误方式是试图通过招聘或借调更多的人来解决软件项目的进度问题。随着项目参与的人越来越多，分工越来越细，人和人之间需要的沟通量也会呈指数级增长。过了一个临界点，人越多反而会越添乱，沟通花费的时间渐渐超过了分工协作节省下来的时间。

软件复杂性的治理需要从多个方面入手。首先，必须重视软件架构的设计和演进。虽然软件架构师无法预见软件最终的形态，但他们可以通过合理的架构设计、持续的架构评审和相应的代码评审，控制复杂性的增长。其次，要建立健全研发流程和工具体系，确保团队高效协作，降低不必要的沟通成本和协同复杂性。

长期来看，控制软件复杂性还需要在团队文化和技术管理上做出持续的努力。首先，必须建立良好的技术文化，鼓励团队成员关注代码质量，避免短视带来的技术债务。其次，要在技术管理上采取合理的策略，如定期进行代码重构、技术债务清理和架构优化，确保系统的健康发展。

John Ousterhout（约翰·奥斯特豪特）教授所著的《软件设计的哲学》正是一本深入浅出地探讨这些复杂性和挑战的书。本书深入剖析了软件设计过程中面临的各种问题，并提供了应对这些问题的思路和方法。这不仅是一本关于技术的书，更是一部关于软件设计思维方式和方法论的经典著作。通过阅读本书，读者可以更好地理解软件复杂性的来源和影响，掌握有效的复杂性治理策略和非常具体的实践方法，从而在软件研发的道路上走得更远、更稳、更有信心。

选择翻译本书，源于我对软件设计领域的浓厚兴趣和对John Ousterhout教授思想的高度认同。在阅读原书的过程中，我深感其内容的丰富和思想的深刻，迫切希望能够将这些宝贵的知识分享给更多的中文读者。Ousterhout教授在书中创新性地提出了战术性编程（tactical programming）和战略性编程（strategic programming）的理念，这两个理念帮助开发者理解和区分在编写代码时基于短期主义思考和长期主义思考的决策和影响。Ousterhout教授强调，优秀的软件设计者需要在战术性编程和战略性编程之间找到平衡。另外，Ousterhout教授对于代码注释也提出了非常犀利且实用的见解和观点，相信对于软件设计者会有很多启发。

感谢合译者王海鹏，他对软件设计的深刻理解及扎实的语言文字功底使本书的翻译质量得到了充分保障。在翻译过程中，我和王海鹏始终秉持忠实于原著、力求准确传达作者意图的原则。为了确保翻译的质量，我们不仅对原书进行了多次细致的研读，还参考了大量相关的技术文献和资料。同时，我们也与一些软件设计领域的专家进行了深入的交流，以确保译文的专业性和准确性。

最后，希望本书能为读者提供有价值的见解和启示，在长期主义的指导下，帮助大家在面对软件复杂性的挑战时，找到合适的解决方案，实现高效、高质量、稳定的软件开发。