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

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

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

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

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

　　任务列表法

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

　　完全穷尽是什么意思呢？

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

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

　　各自独立是什么意思呢？

　　意味着，每一项任务都可以单独做完，而不需要先做完其中一项任务，才能做另一项。

　　假如我有三项任务：任务1、任务2、任务3。

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

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

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

　　PDCA

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

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

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