最近观察到这样一种情况,项目组内的两位比较资深同事似乎都习惯于这样来编码:他们可能会花上两、三周时间将一个模块的成百上千行代码一气呵成的编写完,然后再去与其他人编写的代码集成在一起编译,测试,最终提交。这种情况让我有些惊讶,因为我觉得一个良好的编码节奏不应该是这样的,原因有三:

.这样的节奏不利于问题的早发现早解决

 我们都知道问题发现越早,其解决成本越小。如果只是一味地编写代码,甚至连一次编译都不做,又怎么可能尽早发现自己代码中的问题?怎么可能提早发现其他人的提交对你的模块可能带来的影响呢?这样下去的最终结果很可能是大量的返工或某个隐藏很深的问题,需要花费你较大力气去解决。

.这样的节奏还可能会导致激情疲劳

 激情也会产生疲劳。想必很多朋友都有过类似的经历:一旦长时间投入在一件事情上,如若没有阶段性的成果或者中途遇到一些挫折,那激情也会疲劳,甚至是丧失。程序员都是很有激情的!你一定见过那些整天以方便食品度日,为了某个功能奋战N天N宿的蓬头垢面的程序员们。他们埋头于键盘与屏幕间,将用智慧加工后的字符输入到计算机中。但程序员也是人,如果一直这么下去,没有阶段性反馈,渐渐地,他们的效率就会降低,思维就会僵化,最终导致结果远不如预期。

.这样的节奏不利于自身信心的建立

 在这样只有编码,没有编译,没有必要单元测试的情况下,你如何确保代码质量是没问题的呢?你是否敢于站出来对着大家说我编写的代码是牢不可摧的。显然你不能,因为你没有收到任何关于代码质量评估的反馈。甚至于你的代码是否可以正确地通过编译器的检查都未曾而知,你又哪里有对代码的那份自信呢?

好了,说了这么多原因,那什么样的节奏算是良好的节奏呢?用一句话概括就是“小步快跑,迭代进行,循序渐进”。其主旨在于划大为小、快速完成、快速反馈(通过构建、单元测试)、快速调整,依此循环往复。划大为小是基础,也是一种任务分解的能力;快速完成和反馈能让你及早发现问题,包括自身的以及与他人集成过程中的;快速调整意为迅速应对发现的问题,及时变更设计、重构代码,直至满足。这样每轮下来,你会发现已经完成的任务都是相对健壮的,这种健壮同时也会给你一种正面的反馈,让你保持继续的激情和动力,同时也会给你带来充足的信心。这样一轮一轮下去,你就会持续不断地得到正反馈,这会促使你最终得到一个相对比较健壮的成果物,你的信心也会因此得到倍增。

如果你和我的同事采用了同样的编码节奏,那你不妨尝试调整一下^_^。