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