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

# 快速编程的秘诀：停止思考 » Code Simplicity 来源：https://www.codesimplicity.com/post/the-secret-of-fast-programming-stop-thinking/ 当我和开发者谈论代码复杂性时，他们经常说，自己*想*写出简单的代码，但截止日期带来的压力或一些深层问题，让他们根本没有足够的时间或必要的知识，既完成任务，又将代码打磨得足够简单。 的确，给开发者施加时间压力，往往会导致他们写出复杂的代码。然而，截止日期并*不一定*会导致复杂性。与其说“这个截止日期让我没法写出简单的代码”，也可以说“我的编程速度还不够快，无法把它写得简单”。也就是说，你编程的速度越快，截止日期对代码质量的影响就越小。 这话说起来很好，但究竟怎样才能*变得*更快呢？这是一种与生俱来的神奇技能吗？你要比别人更“聪明”，才能变快吗？ 不，这既不神奇，也不是天生的。事实上，只有一条简单的规则，只要遵循它，最终就能彻底解决这个问题： > **每当你发现自己停下来思考，就说明某个地方出了问题。** 这听起来或许难以置信，但效果出奇地好。想想看——当你坐在编辑器前，却写代码写得不够快时，是因为你打字慢吗？我很怀疑——“要打的字太多”很少是影响开发者生产力的问题。真正拖慢速度的，是那些你*没有*打字的停顿。而开发者在这些停顿期间通常在做什么呢？停下来思考——也许是在想问题，也许是在想工具，也许是在想电子邮件，诸如此类。但每当这种情况发生，都表明有问题存在。 思考本身并不是问题——它是其他问题的一个*信号*。背后可能有很多不同的原因： ### 理解 > **开发者停下来思考，最常见的原因是他们没有完全理解某个词或符号。** 就在前几天，我自己也遇到了这种情况。我花了好几个小时，才写出一个本应非常简单的服务。我不断停下来思考，试图弄清它应该如何运行。最后，我意识到，自己并不理解主函数的一个输入变量。我知道它的类型*名称*，却从来没有去读过这个类型的定义——我并没有真正*理解*这个变量（一个词或符号）的含义。我一查阅这个类型的代码和文档，一切就都清楚了，接着我就像个*魔鬼*一样飞快地写完了那个服务（这里多少有点双关，指守护进程 daemon）。 这种情况的表现形式几乎无穷无尽。很多人一头扎进一门编程语言，却没有弄清楚 (, ), \[, \], {, }, +, *, 和 % 在这门语言里究竟意味着什么。有些开发者不了解计算机真正的工作原理。还记得我写的《明星程序员的唯一秘诀》(https://www.codesimplicity.com/post/the-singular-secret-of-the-rockstar-programmer/) 吗？原因就在这里！因为当你真正理解时，就不必停下来思考。这也是我写这本书 (https://www.codesimplicity.com/book/) 的一个主要动机——理解软件设计中存在着不可动摇的法则，可以消除很多“停下来思考”的时刻。 所以，如果你发现自己停下来思考，不要试图只在脑海里解决问题——到自身之外去寻找你没有理解的东西。然后，去*看看*能帮助你理解它的事物。即便是“用户会读这段文字吗？”这样的问题，也适用这个方法。你可能没有用户体验研究部门来切实回答这个问题，但至少可以画个草图，拿给别人看，问问他们的意见。不要只是坐在那里想——*做点什么*。只有行动才能带来理解。 ### 画图 有时，开发者停下来思考，是因为他们无法同时在脑海里容纳足够多的概念——很多事物以复杂的方式相互关联，他们必须在脑中梳理清楚。在这种情况下，把东西写下来或画出来，几乎总比只在脑子里想更高效。你需要的是某种能够*看见*的东西，或者以某种方式从自身之外感知到的东西。这也是理解的一种形式，但它足够特殊，所以我想单独拿出来讲一讲。 ### 开始 有时，问题是“我完全不知道该从什么代码开始写”。这里最简单的解决办法，就是开始写任何你确定自己现在*能*写的代码。挑出问题中你*完全*理解的部分，为它写出解决方案——哪怕只是一个函数，或一个不重要的类。 通常，最容易着手的代码就是应用程序的“核心”。例如，如果我要写一个 YouTube 应用，我会从视频播放器开始。把它当作一次持续交付练习——先写出真正能构成一个*产品*的代码，无论这个产品多么简陋或微小。一个没有任何其他用户界面的视频播放器，也是一个能做有用事情（播放视频）的产品，即便它还不是一个*完整*的产品。 如果你连这部分核心代码该怎么写都还不确定，那就从你*确定*的代码开始。我通常发现，一旦问题的一部分得到解决，剩下的部分就容易解决得多。有时，问题会一步步展开——你解决一个部分，下一部分的解决方案就变得显而易见，如此继续。哪个部分不需要太多思考就能写出来，就现在把那个部分写出来。 ### 跳过步骤 还有一种特殊的理解问题，就是你跳过了正确开发顺序中的某个步骤。例如，假设我们的 Bike 对象依赖于 Wheels、Pedals 和 Frame 对象。如果你还没有编写 Wheels、Pedals 或 Frame 对象，就试图写完整个 Bike 对象，那么你就得对那些尚不存在的类进行大量*思考*。另一方面，如果完全没有 Bike 类，你就开始写 Wheels 类，那么你可能又得花很多心思思考 Bike 类将如何使用 Wheels 类。 正确的解决办法是，先实现 Bike 类的一部分，直到需要 Wheels 为止。然后，再编写 Wheels 类的一部分，满足 Bike 类当前的需求。接着回到 Bike 类，继续开发，直到下一次需要某个底层组件。就像“开始”一节所说的，找到问题中你不需要思考就能解决的部分，并立即解决它。 不要跳过系统开发中的步骤，还指望自己能高效工作。 ### 身体问题 如果我没吃饱，就容易分心，因为肚子饿而开始胡思乱想。我想的可能并不是*关于*肚子的事，但如果吃饱了，我就*不会*想这些——我会专心工作。睡眠不足、生病或任何身体问题，都可能导致这种情况。它不像前面提到的“理解”问题那么常见，所以首先始终应该寻找你没有完全理解的东西。如果你真的确定自己理解了*一切*，那么身体问题就可能是一个原因。 ### 干扰 当开发者被外界事物干扰，比如噪声，他们可能需要想一会儿，才能记起自己的解决方案进展到了哪里。这里的答案相对简单——开始开发之前，确保自己身处一个不会分散注意力的环境，或者设法让干扰无法打断你。有些人关上办公室的门，有些人戴上耳机，有些人挂上“请勿打扰”的牌子——采取任何必要的措施。你可能需要与经理或同事合作，为开发营造一个真正不受干扰的环境。 ### 自我怀疑 有时，开发者坐着思考，是因为他们对自己或自己的决定没有把握。解决方法与“理解”一节中的方法类似——无论你对什么不确定，都进一步了解它，直到你有足够的把握去写代码。如果你只是对自己作为程序员的能力普遍缺乏信心，那可能意味着还有*很多*东西需要进一步学习，比如《为什么程序员很差劲》(https://www.codesimplicity.com/post/why-programmers-suck/) 中列出的那些基础知识。逐一学习你需要掌握的内容，直到真正理解，再继续学习下一部分，如此反复。编程过程中总会涉及学习，但随着你了解得越来越多，速度也会越来越快，需要思考的地方则会越来越少。 ### 错误观念 很多人被告知，聪明人善于思考，因此，他们会停下来思考，以便做出明智的决定。然而，这是一个错误的观念。如果光靠思考就能成为天才，那么*每个人*都会是爱因斯坦。真正聪明的人会学习、观察、决策和行动。他们获取知识，再用这些知识解决眼前的问题。如果你真的想变得聪明，就用你的智慧在现实世界中推动行动——不要只用它在脑海里构想伟大的思想。 ### 注意事项 以上所有内容，都是*当你坐下来写代码时*成为快速程序员的秘诀。如果你整天忙于读邮件和开会，那么根本就没有进行任何编程——那是另一个问题。其中某些方面是*相似的*（这有点像整个组织“停下来思考”），但并不是同一个问题。 不过，你还是可以尝试一些类似的解决办法。也许组织并没有完全理解*你*或你的角色，所以才给你发那么多邮件，让你参加那么多会议。也许你对组织的某些方面还不完全了解，比如如何减少开会和收到的邮件。🙂 甚至有些组织层面的困难，也许可以通过将本文的解决办法从个人调整为适用于群体来解决。 \-Max