没人知道大型软件是怎么运行的

好文翻译，原文链接

https://www.seangoedecke.com/nobody-knows-how-software-products-work/

大型、快速发展的科技公司常常在对自己系统的“战争迷雾”（fog of war，比喻信息不明、局势混沌的状态）中运作。像“Y类用户能访问X功能吗？”、“在此情境下执行Z操作会发生什么？”甚至“我们到底提供几种套餐？”这类简单问题，往往只有组织里寥寥数人答得出来。有时，组织里 没有一个人 能答上来，必须指派某人像研究员一样深挖代码、反复实验才能搞清。

这怎么可能？写软件的工程师不该知道软件能做什么吗？这些答案不是都有内部文档吗？更别说，翻翻面向用户的公开文档，难道不是分分钟就答上来？科技公司里满是高薪且懂行的人¹，怎么这些人对自己产品到底咋回事都说不清楚？

软件很复杂

大型软件产品复杂到令人望而却步 。我在《邪恶特性》（Wicked Features）里写过很多，简言之，加复杂功能确实能捞到 大量 价值。经典例子就是那些让核心产品覆盖更多用户的功能：比如软件自托管、免费试用、带集中策略控制的大型组织使用、多语言本地化、在软件监管严格的国家落地，或是让政府这类高度受监管的客户使用，等等。这些功能（但愿）对大多数用户是透明的， 但对科技公司自己来说，它们不可能透明 。

为啥复杂？因为 它们会影响你之后写的每一个功能 。加了组织和策略控制，以后每个新功能都得配上策略控制；做了本地化，每个新功能都要带翻译……这么一来，迟早会遇到一个问题：欧盟的自托管企业客户到底有没有权限用某个功能？—— 没人知道 ，你只能去通读代码或者做实验来搞清楚。

难道一开始就别做这些功能不就好了？当然行，但那等于把 大把钞票扔在桌上 ²。说实话，小公司和大公司最大的区别可能就在于：大公司就是靠死磕这些又琐碎又别扭的功能，才能捞到更多价值。

文档

为啥不在开发新功能时，顺手把交互逻辑都记成文档？理论上讲，加上大量投入和高层支持，这事能成，但实践起来真的太难了。

核心问题是： 你边记，系统边变 。一个复杂但静态的系统，给够时间，一个人慢慢磨也能把文档磨出来。可一旦系统开始变，写文档的人就得跑得比系统变化还快——没有离谱级别的人力，这几乎不可能做到。

更要命的是，系统的很多行为背后压根没有（或者说很少有）明确的设计意图。它们就是从系统搭建方式里“长”出来的，是一连串“默认”选择互动的结果。所以写文档的人不只是记录工程师做的决定， 他们自己也是第一次发现这系统到底是怎么跑的 。

那么谁知道答案？

要回答这类问题，唯一靠谱的办法就是去看代码库。我觉得这其实是工程师在大科技公司里拥有机构权力的结构性原因。当然，工程师是 写 软件的人，但几乎更重要的是——他们是能 回答软件问题 的人。

实际上， 回答软件问题的能力，是工程团队的核心职能之一 。对某块软件理解最深的人，通常是天天跟它打交道的工程师。如果代码库由一个健康的工程团队维护，你根本不用派人去“查”——直接问团队，至少会有一个工程师张口就能答上来，因为他对那块代码已经熟透了。

科技公司重组团队时，常常会毁掉这种默会知识（tacit knowledge）。一旦没有团队对某块软件有经验，问题就只能靠 调查 来解决：派个工程师去搞清楚。通常做法是：跟产品交互（比如在好搭场景的开发环境里）、通读代码库，甚至做“探索性手术”（exploratory surgery，指改几行代码或强制某些判断恒为真，看系统反应）。这和写代码是两套技术（当然也有交集）。

写软件比解释软件容易

依我看，多数工程师能写软件，但没几个能可靠地回答软件问题。我不知道为啥会这样——写新功能难道不需要先弄清软件现状吗？但事实就是如此。我猜最靠谱的解释是： 这是信心问题 。很多工程师宁愿为自己的 代码 （至少在自己机器上能跑）背锅，也不愿为自己的 回答 （可能全错）担责。

我在《如何为非技术领导者提供技术清晰度》（How I provide technical clarity to non-technical leaders）里写过这个。核心难点是： 你永远在冒险 。你得坦然接受自己可能大错特错——这和写代码的心态完全不一样（写代码时你常能证明自己写对了）。另外，写代码时可以尽情啰嗦（尤其是写测试时），但回答问题你必须把事儿浓缩成几句。很多软件工程师 特烦 省略细节。

总结

非技术人员——至少没怎么深度接触过软件产品的人——往往以为软件系统被它的建造者彻底搞清楚了。他们的逻辑是：系统一行一行代码垒起来，组件（大体上）是确定的，那它就该是可理解的。

然而，这对小块软件或许成立， 对大型软件系统几乎从不成立 。大型软件系统被理解得极差，哪怕是那些最有资格搞懂它的人也一样。甚至“软件到底能干嘛”这种基本问题，也常常需要 调研 才能答上来。而且好不容易得出一个确切答案，它也不会确切太久——代码库每次变动都可能带出新的细节和例外，于是同一个问题你得反复查。

正因为这样， 准确回答大型软件系统问题的能力，值大钱 。

#大型软件系统 #复杂性 #战争迷雾 #文档困境 #默会知识 #调查能力 #工程师权力 #价值获取 #信心问题 #软件理解