这是Code Simplicity上的一篇文章，分析了影响编程效率的原因，认为主要是在编程中停下来思考而导致的，又根据各种停下来思考的情形给出了相应的解决方案。如果你对提升编程效率和质量也有相关的困惑，可以阅读和参考一下。
当我与开发人员谈起代码复杂性时，常听到的是，他们原本想编写简单的代码，但是由于截止日期的压力，或潜在的其它问题，导致没有足够时间或知识来完成任务并将其简单化。
确实如此，给开发人员施加时间上的压力，是他们编写复杂代码的常见原因。但是，我们也要看清楚，截止时间并不一定会导致复杂性。与其说“截止日期阻止我编写简单的代码”，不如说“我不是一个足够快的程序员，无法将任务简单化。”换言之，作为一个程序员，如果你的速度够快，你的代码质量受截止日期的影响就越小。
（译注：虽然不是所有的情况都是如此，但是我们只针对那些适合的情况来探讨，这样就变得有意义了）
对编程速度和质量的关系有了正确认识，我们再继续往下探讨。
现在的问题变成了：怎么能变得更快呢？这是与生俱来的吗？是否可以通过一些方法来让自己变得“更聪明”、更快呢？
这里先抛出一个答案，那就是这种快速编程的能力根本不是魔法或天才才具有的，而只需要遵循一个简单的法则。
一旦你停下来思考，就表明存在问题。
这听起来荒谬可笑，但事实的确如此。我们来想想看，当你编码速度不够快时，是因为你的打字速度缓慢吗？我不认为是这样，不是因为我们需要打太多字而影响了生产力，而是没有在打字的停顿才是让编程变慢的原因。在暂停期间，开发人员通常在做什么呢？一般是停下来思考一下，或者是关于问题，或者是关于工具，也或者是被即时通讯讯息打扰，等等。每当发生这种情况，就意味着存在问题，这就是我们的突破点。
而思考本身并不是问题，只是问题的征兆，需要根据具体情况分别来看。
开发人员停下来思考的最常见原因，是他们没有完全理解某些单词或符号。
这是发生在我身上的事，就在前几天。我居然花了几个小时，来写一个本该非常简单的服务。期间，我不住地停下来思考，试图弄清楚它会如何运行。后来，我意识到，是我对主函数的一个输入变量并不了解导致的。我虽然知道它的类型名称，但是从来没有去阅读类型的定义。也就是说，我并不真正理解那个变量（一个单词或符号）的含义。而一旦我查找了该类型的代码和文档，一切就开始变得清晰起来。
这种情况几乎时时刻刻在以各种方式上演。许多人深入使用某个编程语言，却没有弄清（，），[，]，{，}，+，*和%在该语言中的真正含义。而另一些人则在不了解计算机的真正工作原理下编程。还记得我在《明星程序员的奇异秘密》这本书里所说的吗？这就是为什么！因为当你真正理解时，你就不必停下来思考。这也是我本书背后的一个主要动机——了解软件设计中存在不可动摇的定律，可以消除许多“停下来思考”的时刻。
因此，如果你发现自己在停下来思考，那么，不要试图通过思考去解决你脑海中的问题，而是在你自己之外来寻找你不理解的东西，去看看一些可以帮助你理解它的东西。这种方法甚至适用于诸如“用户会阅读此文本吗？”这种问题。可能没有一个UX部门来真正回答这个问题，但你至少可以画一幅画，把它展示给某个人，并询问他们的意见，而不要只是坐在那里思考。行动起来，做点什么，只有行动才能带来理解。
而另外一些情况是，当我们停下来思考，是因为事物的关联太复杂，我们必须仔细思考，而我们无法同时在脑海中容纳所有的概念。这种情况下，把它们写下来或者是画下来，几乎总是比在头脑中单纯思考更有效。你想要的是你可以看的东西，或者以某种方式进行感知，这是一种理解事物的形式，但它足够特别，我想自己把它呼唤出来。
而有些时候，问题是“我不知道该先开始编写哪些代码”。这里有个简单的方法，就是开始编写那些已知如何编写的代码。选择您完全理解的那部分问题，并为其编写解决方案，即使它可能只是一个函数，或一个不重要的类。
通常，最简单的代码段是应用程序的核心。比如，如果我要编写一个YouTube应用程序，我会从视频播放器开始，把它当做持续交付的一个练习，让它首先制造一个产品，无论这个产品有多粗糙或多小。虽然没有UI，但是视频播放器也可以做一些有用的事情，即使它还不是一个完整的产品。
如果您还不确定如何编写核心代码，那么只需要从您最确定的代码开始即可。通常，我们发现，一旦问题的一部分得到解决，再解决其余部分就变得容易很多。有时，问题会逐步展开，我们先解决一部分，下一部分的解决方案就显而易见，以此类推。总之，无论哪个部分不需要太多的思考，现在就开始写出该部分。
还有一种造成理解困难的情况，是跳过了正确开发顺序的某个步骤。例如，假设我们的自行车对象依赖于车轮、脚踏板和车身对象。如果您尝试在不编写车轮、踏板或车身的情况下编写整个自行车对象，则必须对这些尚不存在的类进行大量的思考。还有就是，如果根本没有自行车类的情况下，去编写车轮类，则可能需要考虑自行车类将如何使用车轮类。
正确的解决方案是先实现自行车类的大部分代码，以达到需要车轮类的程度，然后编写足够的车轮类，以满足自行车类中的迫切需求，接着回去处理自行车类，直到下次需要一个底层的部分。就像前面章节讲述如何开始那样，找到你可以不假思索解决问题的部分，并立即解决它。
总之，不要试图跳过开发过程中的步骤，这会影响工作效率。
如果我吃得不够多，我往往会因为饿了而分心，并开始思考。而如果我吃饱了，就会集中注意力，不会乱想。这也可能发生在睡眠、疾病，或任何类型的身体问题中。这类问题并不像之前的问题那样普遍，所以，首先还是要解决理解问题，然后才考虑身体相关问题。
当开发人员被外部因素（如噪音）分散注意力后，可能需要一些思考才能重新回到他们在解决方案中的位置。对付这种问题，相对简单。在你开始开发之前，确保你所处的环境不会分散你的注意力，或者分心也无法打断你。有些人会关上办公室的门，有些人则会戴上耳机，有些人会竖起“请勿打扰”的标志，总之，可以采用各种方法，不惜代价。也可能需要与经理或同事协作，以创建一个真正没有打扰的开发环境。
有时，开发人员进入思考，是因为他们不能确定他们的决定。此问题的解决方案类似于处理理解问题的方案，那就是，无论对什么不确定，请详细了解它，直到有了足够的确定性后，再开始编码。如果对如何编程不确定，那么仔细阅读你需要学习的每一部分，直到你真正理解它，然后继续下一部分，以此类推。编程过程中，总会夹杂着学习，但随着你对它的了解越来越多，你会变得越来越快，不得不思考额越来越少。
许多人被告知，思考是聪明人所做的事情，因此，他们停下来思考以做出明智的决定。但是，这是一个错误的想法。如果单凭思考就能让你成为天才，那么每个人都会是爱因斯坦。学习、观察、决定和行动，这才是真正聪明的人做的事。他们获得知识，然后利用这些知识来解决他们面前的问题。如果你真的想变得聪明，就用你的智慧在物质宇宙中引起行动，而不要仅仅是用它来对自己想一些伟大的想法。
以上这些内容，就是当您坐着编写代码时，成为快速程序员的秘诀。如果您整天忙于阅读邮件和开会，根本就没有在编程，和这不是同类问题，虽然某些方面相似（有点像整个组织在停下来思考），但它是不一样的。
不过，您可以尝试一些类似的解决方案。也许组织并不完全了解您或者您的角色，以至于向您发送了如此多的邮件，并让您参加如此多的会议。也许组织中有一些您不完全了解的地方，比如如何参加更少的会议，并减少电子邮件。
也许，一些组织的问题，也可以通过将本文的解决方案透过一群人来解决。
联系客服
