大道至简：解决问题的三大法则
神译局是36氪旗下编译团队，关注科技、商业、职场、生活等领域，重点介绍国外的新技术、新观点、新风向。
编者按：总来的来说，所有工作基本上都是要解决问题。如何解决问题？不同领域有不同的具体方案。但殊途同归，大道至简。如果你能够掌握一些基本原则，则不管是什么领域的问题，不管问题有多复杂，都可以迎刃而解。只是越是看起来简单的东西，做起来越难。文章来自编译。
几十年来，我一直都在给我的团队传授一些‘标准技巧’；我在努力将它们写下来，好让这些知识更容易获取。有三条法则也许是我重复得最多的。我经常称之为‘设计’规则，但实际上，它们是可以用来解决从机器到人类的任何类型问题的工具。
以下三条法则我经常会跟团队讲，通常每周都要重复几次。其实里面的每一条表面上都很简单，甚至有点陈腐，但是如果你深挖进去，弄清楚它的意义，并且试图遵循的话，你就会意识到它们往往是违反直觉的，并且需要你付出努力才行。但我的经验是，只要遵循这些法则，就可以解决看似棘手的问题。
按重要性降序排列这三大法则分别是：
如果你想去某个地方，首先要弄清楚你想去的是什么地方，然后再想办法去到那里。
要爱上你正在解决的问题，而不是你想出来的具体解决方案；因为问题是持久的，方案只是暂时的。
任何与魔法有异的技术都不够先进。
以下是对每一条法则含义的简要解释，并附上一个关于击剑的故事，通过故事也许可以解释为什么我会选择出这三条法则。
法则一
如果这篇文章你只能记住一样东西，那就请记住这个；我发现这一条对于解决任何问题都是必要的。这一条看起来十分的简单明了，但要想做到可能会非常具有挑战性。
如果你想去某个地方，首先要弄清楚你想去的是什么地方，然后再想办法去到那里。
这其中的关键词不像看起来那么明显：“然后”。这句话的步骤是有先后顺序的，至关重要的是不要将它们混为一谈。
当你试图解决一个问题时，很容易就会先考虑自己现在处在什么位置——当前是什么情况、你过去做过什么样的权衡取舍、哪些是自己擅长的、什么是你的客户过去喜欢的——然后就会问“我正在做的事情该如何进行调整才能让事情变得更好？”做这件事情似乎很明显是正确的。
但这么做的问题是，如果你是这样计划的话，其实暗地里也在为你今天陷入的各种不好的东西做打算。你正寻找怎么做出尽可能小的改变就能达到目的，但这未必能带你接近自己真正想去的地方。这就像在迷宫里面走来走去：最靠近出口的转角不一定能让你真正走到出口。更有可能的是，它会让你沿着一连串看似更逼近目标的途径走下去，但最后却走到了死胡同。
在工程项目里，我一遍又一遍地看到这种情况的发生：团队进行了一系列的小改动，却没有意识到他们构建的系统甚至都不再满足客户的基本需求了，而那些仍留下来的客户之所以没走只是因为他们自己对改变的代价也感到害怕——他们一直熬，直到有一天他们再也熬不住。然后客户离开了，而你没有办法让他们回来，因为你没有为到达你真正需要去的地方做任何投资。
避免这种情况的方法是区分清楚这两个步骤。首先，弄清楚你想去哪里：需要解决的问题是什么？谁关心你解决这些问题？他们实际上想要从解决方案得到什么？一个好的解决方案是什么样的？一个违反直觉的技巧，感觉就像你在作弊甚至“做错了设计”，那就是做一个干净的设计，要完全无视你有什么，只让自己受到能做什么的约束，而不去参考你有什么。其输出是你想去的那个地方的清晰画面。只有当你的脑海里有了清晰的画面之后，你才会问自己应该如何从这里走到那里——现在这变成了一个更具体的问题，而且往往与你只是调整当前解决方案时的行动方式大不相同。
说得更详细一点，我通常都会希望团队在每个阶段当中采取一些具体步骤。每当考虑下一步该做什么时，我们首先都要进入全新的设计阶段。在这个阶段，要提出三个关键问题：
我们试图解决的问题是什么？
谁对我们解决（或不解决！）问题很关心？他们同意我们对问题的构想吗？
好的（但可实现的）解决方案是什么样的？这些人是否同意有这样的解决方案是解决问题的好方法？它有没有遗漏了什么？
你得按这个顺序去询问他们，并且要特别强调确保大家达成一致。以书面形式执行这些步骤，而不仅仅是口头上：根据我的经验，如果两个人只是口头讨论的话很容易就会把自己的想象强加在别人身上，以为自己不说别人也是这么想的。用静态形式向人们展示答案，确保对正在讨论的内容没有歧义，这一点是不可替代的。
（我见过的最严重的组织错误都可以归结为在这一条上面做错了。情况好一点的结果是，团队投入了多年的工作和数亿美元，最后开发出一个没人想要的解决方案；情况糟糕的结果是，好心办坏事，因为每个人似乎达成了模糊的一致，却没人意识到实际要完成的是什么。如果说改进组织流程有什么可以做的事情的话，那就是当你要着手解决一个问题时，永远都要从这三个问题开始，而且永远要用书面的形式，永远不断迭代，直到所有各方都同意上面所说的内容。）
一旦你对这三个问题有了答案，并且知道你想去哪里，接下来就进入了规划阶段。下次我会更深入地介绍这一阶段，但关键思想是把这项工作分成多个里程碑。
什么样的里程碑才是好的里程碑？其关键特征并不直观：“推出产品”不算好的里程碑。相反，你的目标是在每个里程碑都能获得真正的价值。如果你在达到任何一个里程碑后停止整个项目，你也几乎不会觉得时间被浪费掉了——无论是对问题有了更好的理解，还是对问题给出了某些方面的解决方案，你在那个里程碑上取得的成就本身是有价值的。
为什么？因为当你达到任何特定里程碑时，情况可能已经发生改变，优先级可能已经转移，整个问题可能不再是你想要关注的事情。有很多很好的理由可以说明放弃该项目是明智之举。但是，如果每个里程碑都标志着成功获取价值的话，那你们的付出就不是浪费。
法则二
这种放弃的可能性就引出了设计的第二条法则，这一条也一样看似简单，但其实在深层次上是有违直觉的。
你开发的系统是达到目的的手段；每一个系统都是暂时的，总有一天会成为你要做斗争的碍手碍脚的垃圾。不要爱上你的系统；你该爱上的是要解决的问题。
这个也是很有诱惑性的，尤其是我们为此已经花费了多年的努力，已经爱上了我们开发的系统，本能上对于任何要替换掉它们的建议都会抵触。但这是把过去和未来混为一谈：这些系统之所以受到喜爱，是因为它们让事情变得更好了，因为它们真正改善了世界。如果系统已经到了可以被替换的地步，那并不意味着系统失败了——远非如此，这意味着系统已经成功过，它们的旅程走完了，是时候光荣退休了。它们（知识上）的继任者是它们的孩子，是根据我们从开发和使用它们中学到的一切创造出来的；我们希望它们的继任者比它们更好，就像我们希望自己的孩子有朝一日能超越我们一样。
想想很有趣，但到目前为止，我职业生涯当中最快乐的日子之一是当我开发的一个系统退休的那一刻——曾几何时，谷歌搜索显示的 20 份文档里面有 19 份都是那套系统提供的服务。这套系统做得非常出色；它的开发和维护都非常的微妙，需要我们改变对搜索工作方式的理解，推动了软件和硬件架构的各种变化。但后来它逐步被一个新系统所取代，这个系统由原始团队的继任者开发，他们吸取了我们那十年从那个系统以及其他的系统学到的所有经验教训，并开发出一个甚至能以更好的方式解决新一代问题的新系统。那个新系统实在是太漂亮了。而且我毫不怀疑，出于同样的原因，即使在今天，这套系统自己的替代品也正在朝着它逼近。如果那一天到来，那并不是葬礼；而是一次毕业典礼，一个总结的时刻，去反思取得的成就，并展望未来。
因为它已经实现了自己的目标：我们如何搜索比“传统”搜索引擎的处理能力要大一百倍的互联网？它解决了当时的所有问题，新系统将解决下一代的问题。我们致力于解决能够发现事物以及将知识综合起来的问题；我们开发的工具是解决该问题的关键一步，但那个问题仍然存在。
老实说，大多数问题仍然存在，而不仅仅是在工程方面。拉比 Tarfon 常说：“完成工作不是你的事；但你也不能随意把它放在一边。生命中最值得解决的问题往往是无限期的，不会在我们有生之年解决，也不会在我们孩子的有生之年解决。这意味着我们可以做的是朝着他们的解决方案迈进，解决他们在我们这个时代出现的各个方面，并继续朝着我们的后代可能（ inshallah ！）实现的最终目标迈进。
法则三
亚瑟·克拉克（Arthur C. Clarke）有句名言：“任何足够先进的技术皆与魔法无异。”他的话有很多含义，但我想提请你注意它的反义词：
任何与魔法不同的技术都不够先进。
这句话，有时候又被称为本福德定律，乍一看只不过是抖机灵，一个巧妙的文字游戏，告诉我们得“做得更好！”但其实当我们问自己“魔法”这个词在这种情况下的实际含义，以及与魔法不同是什么意思时，它的真正含义就昭然若揭。
虽然这个词有很多定义，但这句话当中“魔法”的关键显然不是指超自然的起源——如果说有什么区别的话，克拉克陈述的全部要点是“魔法”可以有一个明确的自然起源，并且仍然服务于相同的目的。相反，我要问的是什么首先让魔法变得令人向往：可以这么说，是支配世界的能力，让它以你想要的形式出现。
这个概念其实已经包含在著名的咒语“abracadabra”中，（与普遍的看法相反）它不是胡言乱语；它是阿拉姆语，意思是“让它如我所说那样发生”。从这个角度来看，魔法的核心在于它可以将一个人对世界应该怎样的内在愿景直接转化为物理现实。
这就是这句话重要之意义所在。当一个人的内心愿景未能直接转化为现实，而是需要用户费功夫的步骤才能转换时，一项技术就变得“有别于魔法”了。比方说，我的视觉想象力比我的艺术天赋要生动得多；我可以想象出许多图像，但我没有能力把它画在纸上，哪怕是稍微画一点出来的能力也没有。我也许可以通过几十年的努力习得这些技能，然后花几天、几个月或几年来创作出一幅画，但这与魔术截然不同。
一项技术要真正具备“魔法”，需要做到这几件事：
它应该让你用你构思它时所用的语言来描述你正在想象的东西；
它应该用同一种语言来让你看到世界的当前状态，你用来描述期望世界是什么状态的那种语言；以及
它应该让你用同一种语言来操纵世界的状态，来描述“让它像这样”。
尽管这一条比其他两条范围更狭窄，更具体，但仍在我的三大设计法则中占有一席之地，是因为它说明了我们是如何思考要解决的问题的。回到第一条法则，我们在执行它的第三步——描述出好的解决方案——这条法则就成为定义“好”的关键。更重要的是，它使得与利益相关者进行对话成为可能，这样你才能确定是否真的解决了他们的问题，因为一个需要大量思考和抽象才能使用的系统，也许可以也许不可以做到你想象的事情，并且在这些对话中，如果不具备这一属性的话，双方可能并不真正了解系统能够做什么。
将一个具有魔法的设计的三个属性分离也是有意为之的。描述、查看和操作是共享一门语言所需的三种不同行为——就定义里程碑而言，能够对问题执行这三种动作之一就已经是一大进展。以我的经验，如果一个系统能够用一种易于理解的语言描述清楚已有现实就已经是对人们生活的巨大改善，如果它还能增加改变现实的能力的话，那就更好了。
严格遵守描述这些属性的文字也非常重要。比方说，“查看当前状态”与“查看系统被设置的状态”是不一样的。这是三哩岛给我们的教训：核反应堆的操作员有显示系统当前设置的仪表，在阀门被卡住导致系统的实际状态与设定状态不同的那一天之前，这些仪表都是非常有用的。 （有关这方面的更多详细信息，可参阅 Mahaffey 的《原子事故》第 9 章，自发现原子以来每一次重大核事故的详细事后分析这本书都介绍了。我的朋友兼同事 Lea Kissner向年轻工程师推荐这本书已有一段时间了，我十分支持拿它来作为了解工程会如何出错的一种手段。）
最后，我再讲一个关于击剑的故事
这三条法则单独拎出来看都很简单，但实际上执行到位比看起来要难得多。对这一挑战最好的解释是我从一位朋友，也是我的同事 Nelia Mann 那里了解到的，她曾经是一名高水平的竞技击剑手。她向我解释说，每一位击剑学生的职业生涯都会经历三个阶段：
首先，他们会被教导严格的规则，并努力遵守；
然后，他们达到了一定阶段之后，开始意识到通过改变这些规则他们可以取得一堆胜利，并找出所有改变规则的方法；
最后，当他们接近精通的水平时，他们会重新遵循自己初学时被教导的那些规则——只是这一次，他们已经正确把握了这些规则并照做了。
第一阶段和第三阶段的区别在于是否已经深刻理解对为什么会有这些规则，以及正确或错误执行规则时是什么感觉。你了解到，有些规则其实更像是指南——是你通常会做的事情，但在某些情况下可能会有所不同，并且你可以随时解释为什么它们适用或不适用——而有的规则其实是铁律，是你在工作当中永远都不会考虑去打破的东西。
自打听说了这个故事之后，我多年来的经验是，这三个阶段不仅适用于击剑，也适用于所有的技能。在软件工程当中，那些我在过去几十年一直在学习的技能，你会看到这种模式的出现，也会发现哪个是哪个不是那么的显而易见：比方说，关于互斥锁偏序的“规则”你偶尔确实会违反，虽然有非常丰富的代码注释来向未来的读者解释正在发生的事情和原因，但是关于代码要写注释、记录资源所有权转移，或遵循代码风格指南，这些规则变成了你不会再想违背的东西。在初学者看来更基本且不太重要的规则，其实才是最重要，需要始终完全遵循的规则。
我在上面提出的三条法则，之所以要列出来是因为它们都属于这第二类：这些都不是你只需要大致遵循的规则，而是需要你花时间和精力去完善的规则，你要一直完善到它们变成你的第二天性。上面的思考框架与我刚开始的理解已经相去甚远；它本身就是我花费了数年时间去提炼和提高的结果，现在我对它们、它们的含义和应用的理解已经完全不一样了。我完全可以预计到这些框架会随着时间的推移不断发展和改进，并且甚至可能会适时地被更好的框架所取代（这一点完全符合第二条法则）。
我期待能取得这种改进，但希望与此同时，这些法则能对你有用。
译者：boxi。
