快速编程的秘诀：停止思考

作者：Max Kanat-Alexander
发布日期：2013年12月10日

当我与开发者讨论代码复杂性时，他们常说想写简单的代码，但截止日期压力或潜在问题意味着他们没有足够的时间或知识来完成任务并简化代码。确实，给开发者施加时间压力往往会导致他们编写复杂代码。然而，截止日期不一定会导致复杂性。与其说“这个截止日期阻止我写简单代码”，不如说“我还不够快，无法简化代码”。也就是说，作为程序员，你越快，代码质量受截止日期影响就越小。

这说起来容易，但如何真正变快呢？这是一种与生俱来的神奇技能吗？是通过比别人“更聪明”来变快吗？不，这根本不是魔法或天生的。事实上，有一个简单的规则，如果遵循，最终会完全解决问题：每当你发现自己停下来思考时，就说明有问题。

这听起来可能不可思议，但效果非常好。想一想——当你坐在编辑器前但编码不快时，是因为你打字慢吗？我怀疑不是——“打字太多”很少是开发者的生产力问题。相反，不打字时的停顿才是慢的原因。开发者在这些停顿期间通常做什么？停下来思考——可能是关于问题、工具、电子邮件等。但每当这种情况发生，都表明有问题。

思考本身不是问题——它是其他问题的标志。可能是许多不同问题之一：

理解

开发者停下来思考的最常见原因是他们没有完全理解某个词或符号。前几天我就遇到了这种情况。我花了几个小时写一个本应非常简单的服务。我不断停下来思考，试图弄清楚它应该如何行为。最后，我意识到我没有理解主函数的一个输入变量。我知道它的类型名称，但从未去阅读类型的定义——我不真正理解那个变量（一个词或符号）的含义。一旦我查看了类型的代码和文档，一切都变得清晰，我像恶魔一样编写了那个服务（部分双关语 intended）。

这几乎可以以无限种方式发生。许多人在没有学习 (, ), [, ], {, }, +, *, 和 % 在该语言中的真正含义的情况下就潜入编程语言。一些开发者不理解计算机的真正工作原理。记得我写《摇滚明星程序员的单一秘密》吗？这就是原因！因为当你真正理解时，你不需要停下来思考。这也是我书背后的主要动机——理解软件设计有不可动摇的法则可以消除许多“停下来思考”的时刻。

所以，如果你发现自己停下来思考，不要试图在脑海中解决问题——在外部搜索你不理解的东西。然后去看一些能帮助你理解它的东西。这甚至适用于像“用户会读这段文本吗？”这样的问题。你可能没有用户体验研究部门来真正回答这个问题，但你可以至少画个图，展示给某人，并询问他们的意见。不要只是坐在那里思考——做点什么。只有行动才能导致理解。

绘图

有时开发者停下来思考是因为他们无法一次在脑海中容纳足够的概念——许多事物以复杂的方式相互关联，他们必须思考透彻。在这种情况下，写或画点什么几乎总是比思考更高效。你想要的是你可以看的东西，或以某种方式在外部感知的东西。这是一种理解形式，但它足够特殊，我想单独指出。

开始

有时问题是“我不知道该写什么代码开始。”这里最简单的解决方案是开始写你现在知道可以写的任何代码。选择你完全理解的问题部分，并为其编写解决方案——即使它只是一个函数或一个不重要的类。

通常，最简单的代码开始是应用程序的“核心”。例如，如果我要写一个 YouTube 应用，我会从视频播放器开始。将其视为持续交付的练习——首先编写实际能制作产品的代码，无论那个产品多么愚蠢或小。一个没有其他 UI 的视频播放器是一个有用的产品（播放视频），即使它还不是一个完整的产品。

如果你还不确定如何编写那个核心代码，那么就从你确定的代码开始。通常我发现，一旦问题的一部分得到解决，解决其余部分就容易得多。有时问题逐步展开——你解决一部分，这使得下一部分的解决方案变得明显，依此类推。无论哪部分不需要太多思考来创建，现在就写那部分。

跳过步骤

另一个特殊的理解问题是当你跳过了开发正确序列中的某个步骤时。例如，假设我们的 Bike 对象依赖于 Wheels、Pedals 和 Frame 对象。如果你尝试编写整个 Bike 对象而不编写 Wheels、Pedals 或 Frame 对象，你将不得不大量思考那些不存在的类。另一方面，如果根本没有 Bike 类时你编写 Wheels 类，你可能不得不大量思考 Wheels 类将如何被 Bike 类使用。

正确的解决方案是实现足够的 Bike 类以达到需要 Wheels 的点。然后编写足够的 Wheels 类以满足 Bike 类中的即时需求。然后回到 Bike 类，并工作直到下一次你需要一个底层部分。就像“开始”部分一样，找到你可以不加思考解决的问题部分，并立即解决它。

不要跳过系统开发中的步骤并期望自己高效。

身体问题

如果我没有吃够，我往往会分心并开始思考，因为我饿了。可能不是关于胃的想法，但如果我吃饱了我就不会思考——我会专注。睡眠、疾病或任何身体问题也会发生这种情况。它不像上面的“理解”问题那么常见，所以首先总是寻找你没有完全理解的东西。如果你真的确定你理解了一切，那么身体问题可能是一个候选。

分心

当开发者被外部事物分心时，比如噪音，可能需要一些思考来记住他们在解决方案中的位置。这里的答案相对简单——在开始开发之前，确保你处于一个不会分心的环境中，或者使分心无法打断你。有些人关上办公室门，有些人戴上耳机，有些人挂上“请勿打扰”标志——无论需要什么。你可能需要与经理或同事合作，为开发创建一个真正无分心的环境。

自我怀疑

有时开发者坐着思考是因为他们对自己或自己的决定感到不确定。这个问题的解决方案类似于“理解”部分的解决方案——无论你对什么不确定，学习更多直到你足够确定编写代码。如果你作为程序员只是普遍感到不确定，可能有很多东西需要学习，比如《为什么程序员很烂》中列出的基础知识。逐个学习你需要学习的每个部分，直到你真正理解它，然后继续下一个部分，依此类推。编程过程中总会涉及学习，但随着你了解得越来越多，你会变得越来越快，需要思考得越来越少。

错误观念

许多人被告知思考是聪明人所做的，因此，他们停下来思考以做出明智决策。然而，这是一个错误观念。如果仅思考就能让你成为天才，那么每个人都会是爱因斯坦。真正聪明的人学习、观察、决定和行动。他们获得知识，然后使用该知识解决面前的问题。如果你真的想聪明，用你的智慧在物理世界中引起行动——不要只用它来思考伟大的想法。

注意事项

以上所有都是当你坐着写代码时成为快速程序员的秘诀。如果你整天忙于阅读电子邮件和参加会议，那么根本不会发生编程——那是不同的问题。它的某些方面类似（有点像组织“停下来思考”），但不一样。

尽管如此，你可以尝试一些类似的解决方案。也许组织没有完全理解你或你的角色，这就是为什么他们发送这么多电子邮件并让你参加这么多会议。也许有关于组织的东西你没有完全理解，比如如何参加更少的会议和收到更少的电子邮件。甚至一些组织困难可以通过将本文中的解决方案适应人群而不是个人来解决。

-Max

（评论部分省略）