引入新维度化解权衡难题
在软件开发中，有些人认为"快速部署"和"充分测试"是相互冲突的。这是因为完全自动化的部署流程似乎意味着没有时间进行人工的质量保证（QA）。但另一些人则认为：通过使用"特性开关（Feature Flags）"将部署 （发布代码）和发布（启用新功能）解耦，你既能实现快速部署，又能保留人工 QA 的环节。
随着工作经验的积累，我越发认为这个例子揭示了一个做权衡（Tradeoffs）的通用模式：
- 二维的权衡总会让人失望（非此即彼，总有一方要妥协）。
- 引入一个新的维度，通常就能找到让大家都满意的方案。
在"快速 vs 安全"的部署权衡中，新增的维度就是"解耦（将发布代码和启用功能分开）"。这让工程师能快速、可预测地部署代码，同时 QA 也有机会在功能向用户开放前进行审查。
虽然很多人已经凭直觉意识到了这些规律，但我认为明确地表达出来会带来一些启发。接下来我将深入探讨如何应用这些思路。
实际案例
在讨论具体操作之前，我们先看几个引入新维度来化解两难选择的例子：
- 项目预算：在年度规划中，公司常纠结于"投资新市场"还是"优先发展现有市场"。引入"固定预算"这个维度后，就能在两者之间按比例分配，而不是非此即彼。
- 投资组合多元化 ：过去，投资者总是在"安全但收益低"和"高风险可能血本无归"之间挣扎。《漫步华尔街》一书引入了"多元化"的维度，使得投资者既能获得接近股市平均水平的收益，又能降低风险。
- 基于数据的权限控制：产品和安全团队常在"用户安全"和"产品易用性"之间争论。引入"真实使用数据"作为维度后，两全其美的方案就出现了：先移除用户当前根本不用的那些权限。这既提高了安全性，又不会影响易用性。
- 特性开关：正如开头提到的，我们不用在"慢且安全"和"快且危险"的部署中二选一。通过特性开关解耦，我们得到了"快且安全"的方案。
除了这些，你在过往工作中肯定也能找到类似例子。当一个棘手的争论被引入的新维度化解时，那种"非此即彼"的紧迫感就会消失，取而代之的是顺理成章的解决方案。
如何引入新维度
一旦你开始用这种方式思考，就会发现身边早有高手在这么做了。不过他们往往凭的是直觉，很难将其具体步骤解释清楚。我尝试将这个过程逆向工程，总结为以下几个步骤：
- 抱有信念并广而告之：在每次陷入权衡僵局时，你要相信总有一个额外的维度能大大缓解当下的决策压力。把这个想法告诉团队，比如简单地说一句："我在想，能不能给这个问题增加一个维度，让决定变得容易些？"
- 明确所有利益相关者的需求 ：缺失的维度通常藏在细节中。你需要逼迫大家把需求说得非常明确。如果有人说不清楚，那你就得花时间帮他们理清。不要觉得"这是他们的问题"，既然卡住了，现在这也是你的问题。
- 扩展背景知识（上下文） ：寻找新维度就像看透不同的 上下文层级 (Layers of Context)。你需要拓宽自己的认知，或者拉上一个知识面广的团队一起讨论。这些人不一定要是决策者，只要了解相关的团队、技术和产品即可。
- 快速验证新维度的有效性：有了想法后马上问大家："如果加上这个维度，问题会不会变简单？"关键在于要快速试错，不行就换下一个，不要在没见到明显收益前就过度深究某一个维度。
- 向有经验的人请教 ：直接去问那些解决过类似问题的人。这就是为什么建立 同行人脉网 (Network of Peers) 如此重要。他们可能直接就能告诉你那个缺失的维度是什么！
- 只在带来显著好结果时才添加维度：当你习惯这种思维后，可能会忍不住到处加维度。切记：只有当新维度能为各方带来明显更好的结果时才去使用，否则只会让事情变得更复杂、更难解释。
这个过程并不总是奏效，有时团队就是缺乏相关的知识储备，想不到那个缺失的维度。如果一时半会儿找不到也不要气馁。这也是为什么每隔几年重新审视一下那些历史遗留难题是有价值的------过去你不知道的维度，随着经验增长，现在也许就一目了然了。
职业生涯后期的能力
人们常说，工程师工作 5 到 7 年后就能成为资深（Senior）员工，完全胜任本职工作。从某种意义上说这是对的，但这也忽略了许多在这个阶段才刚刚开始萌芽的能力。
"为权衡增加新维度"就是这类高级能力的好例子：很少有人能在早期就积累足够的背景知识和广泛的经验，从而能敏锐地找出缺失的维度来化解复杂难题。在软件开发这条路上，永远都有新东西要学。