编程的精进之法

编程,众所周知被定义为知识工作。所有的知识工作,从业者和门外汉都喜欢把它神秘化,将整个过程以不可知论的风格来解释。理由往往非常简单粗暴,无非是“照搬体力工作时代的工作方式会在知识工作中失败。”

这其实没什么靠谱的理论。偶有几个人能写写理论与理由,也跟癔症者的呓语无甚差别。我个人是反对将知识工作神秘化的,我是科学管理原理的忠实粉丝,尽管科学管理原理的具体案例都过时了,但泰勒的研究方法依然是有效的,只是研究者和被研究者发生了一些微妙的变化。

彼得德鲁克在《21世纪的管理挑战》中提到,“知识工作者需要自我管理”,那么很明显不是体力工作时代形成的方法不能用在知识工作中,而是不能指望个体之外的人对个体进行简单的粗暴的分析和命令,不要妄想以此产生很高的生产效率。这个分析和下命令的人必须是知识工作者自己,我们需要自己纪录自己的行为,然后分析、优化,才能得到生产力的提升,任何向外诉求都会很快的撞上一个“天花板”而无法提升。如果非要寻求外部干预,那么我们只能说,对于新时代的管理者定位,老板更像老师,以引导和帮助训练为主,真正的效率提升主要还是靠自己。

1-floor

那么书归正传,追求知识工作的一种——编程的效率,是本文关注的重点。但我们首先要声明,本文不会给一个可以直接产生高效率的方法,而会给一个可以将生产效率可视化,并从中发现瓶颈的方式。至少在不改变质量的前提下,可以极大的提升你的效率,如果使用得当,可能会得到质量和效率的双提升。

本文引入的方法也并不新鲜,简单说来,就是任务列表法+PDCA的一套组合使用而已。大道至简,坚持者寡,而坚持下来的人往往都可以获得数倍的效率提升。

任务列表法

我们做任何事情都应该划出任务列表,按照列表一项项去完成,这不是什么特别稀奇的工作方式。然而,很多人的问题在于,列出的问题列表不能达到完全穷尽,各自独立。

2-todolist

完全穷尽是什么意思呢?

当我开始做事情的时候,如果不能把所有的事情穷尽,我列出的列表跟我做的事情是不完全等价的,这说明我们的工作行为非常混沌且不可视,哪怕是对自己。

有时,事情看起来在大面上穷尽了,但是做的时候,又会发现新的任务。那说明每一项任务的输入和输出没有想清楚,因此每当发现有所欠缺,就需要输入新的任务作为补充。于是任务列表就增加了,这也是一种没有穷尽。

各自独立是什么意思呢?

意味着,每一项任务都可以单独做完,而不需要先做完其中一项任务,才能做另一项。 假如我有三项任务:任务1、任务2、任务3。

我做的时候,必须把任务2做完,任务1才能做完;任务3做完,任务2才能做完。结果我就从任务1开始一路做到任务3,最后再逐步回到任务1,整个过程非常混乱,那就不是各自独立的。

在现实生活中想做到各项任务都独立,挑战还是比较大的,但是在编程的世界里就轻松多了。优秀的设计都是要求解耦的,如果做不到,基本等于活儿比较烂。

3-fly

当我们做到“任务的完全穷尽与各自独立”之后,我们的任务列表法才算达标,这之后才能高效的工作,然而达到这一点并不是一蹴而就的,没有谁可以一上来就做到任务划分的完全穷尽、各自独立,需要不停的刻意练习。所以我们称之为编程的精进之法。

PDCA

PDCA是Plan-Do-Check-Action四个词的组合。这是著名的戴明环。讲究从计划开始、经过实践、反思、产生的改进行动再纳入下一轮计划的持续改进过程。

当我们把这一套从工业领域搬过来的时候,我们对计划的理解还是工业领域那一套。如果用在个人提升方面,我们应该把PDCA微观化,这之后就有两个问题需要被解答,一个是Plan是什么?一个是Check什么?

第一个问题的答案很显然,我们前面讲的任务列表法就是在形成这个Plan。

第二个问题本身是一个母问题,每当我们对这个问题进行回答,都要回答一个衍生出来的子问题:我们要做点什么才能在需要Check的时候能够Check。

常用的套路有两个:

  • Plan的时候估计一个时间,然后开始做,做的时候计时,做完就要Check这个时间是否达标,无论快了还是慢了(通常是比较明显的差距才能引起反思,比如20%以上的差距),Check都要反思并产生Action,纳入到未来的Plan中去。
  • 估计的任务列表和实际做的任务列表是否是一样多的?往往是会多出来,这时就要反思,自己在哪里有不足导致了这个差别。

这些反思往往是发现自己的问题,比如自己不熟悉的知识点、方法,甚至业务知识,最后的Action也往往都是通过刻意练习来提升生产效率,比如反复练类似题目。有时也会借助一些工具来提升效率,比如抽取live template,使用快捷键,只是效率工具的使用往往也需要刻意练习。有时也可以通过复用技术(其实live template已经是复用技术了)来提升生产效率,然而可复用模式的识别与抽取本身也是需要练习的,否则在那里纠结浪费的时间更长。

有些同学会感觉到,记录了时间却不知道哪里有问题,这个时候可以跟TDD相结合,把时间划分为写测试的时间,写实现的时间和测试通过的时间。其实除去这几种时间,还有其他时间消耗,比如调研的时间。不管怎么划分,将时间消耗结构化掉,一部分一部分的追求最高效率是一种可行的办法。

举例

我们做一个简单的修改用户信息功能的API。那么我们在某一个Java技术栈上可能的任务列表是长这样的:

  1. 写UserController (10分钟)
  2. 写UserDAO (15分钟)

当你真正开始做的时候,会碰到两种主要的意外:

  1. 任务列表扩张
  2. 时间估计不准

下面就这个例子,就讲一讲当我们遇到这两种意外,该怎么反思和处理。

任务列表扩张

任务列表扩张,顾名思义,就是指我们所估计的任务数量会随着我们开始工作变的比