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

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

当我与开发者讨论代码复杂性时，他们常说希望编写简洁的代码，但截止日期的压力或潜在问题意味着他们既没有时间也没有足够的知识来完成任务并将其优化至简洁。

确实，给开发者施加时间压力往往会导致他们编写复杂的代码。然而，截止日期不一定会导致复杂性。与其说“这个截止日期让我无法编写简洁的代码”，不如说“我还不够快，无法让代码变得简洁”。也就是说，作为程序员，你的速度越快，代码质量受截止日期影响的可能性就越小。

这听起来不错，但如何真正变得更快呢？这是一种与生俱来的神奇技能吗？你是否通过比其他人“更聪明”而变得更快？

不，这根本不是魔法或与生俱来的。事实上，只要遵循一个简单的规则，就能最终完全解决问题：每当你发现自己停下来思考时，就说明有问题了。

这听起来可能难以置信，但效果非常好。想想看——当你坐在编辑器前但编码速度不快时，是因为你打字慢吗？我对此表示怀疑——“打字太多”很少是开发者的生产力问题。相反，让你变慢的是那些不打字的停顿时刻。开发者在这些停顿时刻通常做什么？停下来思考——可能是关于问题、工具、电子邮件等等。但每当这种情况发生时，就表明存在问题。

思考本身并不是问题——它是其他问题的征兆。可能是以下多种问题之一：

理解问题

开发者停下来思考的最常见原因是他们没有完全理解某个词或符号。

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

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

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

绘图

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

开始

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

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

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

跳过步骤

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

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

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

身体问题

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

分心

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

自我怀疑

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

错误观念

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

注意事项

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

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

-Max