昨天上午着手开始写代码，一个预计不超过半天就可以完成的小功能，然而事实是，直到今天下班前还未能完成。

虽说计划和实际的差异是司空见惯的事，但还是让我吃了一惊，于是开始反思究竟是计划还是执行出了问题。细想来，计划的确没问题，即便现在我还是能笃定地认为这只是一个不超过半天的小功能，那么一定是执行中出了问题。

在实际做的过程中，涉及到一个前台页面状态筛选的功能，第一步是需要罗列出有些状态，然后这些状态的数据依据是什么，即满足什么样的条件即可被认为是什么状态。一段时间内，我深陷其中，罗列出了几乎所有可能出现的情况，包括正常和异常两大类，而每个大类里又可以分出好多个小类，于是这些个数据依据就变得非常复杂，甚至出现了交叉的情况。在这些逻辑判断面前，我陷入了纠结和困境。

就在提交 SVN 准备明天再战的那一瞬间，我突然意识到，为什么我会需要罗列出各种可能性呢，其实业务真正关心的只是「正常」状态，因为这里所涉及的「异常」状态多是系统级别的，不是业务需要操心的事儿，应该是 IT 运维需要关心的。于是，条件就变得简单了，将正常状态罗列出来，然后也不是所有正常状态都有筛选的意义，只需要挑出其中关键的节点即可。这样一来，逻辑就变得清晰了。

这让我想起了看书的过程，记得有人曾说过，最理想的看书状态是先把书看厚，再把书看薄，大概是精读之后能够总结出言简意赅的精华来为自己所用。「把书看厚」其实是要做到对于书中内容心中有数，「把书看薄」则是要从这整本书中提炼出对于自己有用的东西，过犹不及，并不是多多益善，多往往就伴随着「泛」，很简单的道理，如果所有知识点都重要，那么就没有了「最重要」。

多年以来，我看书的习惯也大抵如此，所以在过去，我看书的速度都很慢，几乎是不愿放过书中的任何细节。直到今年的某一天，大概是实在看不下去自己这“龟速”，于是决定尝试一下辉哥推荐的快速阅读法，所谓「快速阅读法」，第一遍飞快地浏览全书，找到自己最感兴趣的点，这个过程非常快，10-15分钟即可；第二遍细读感兴趣点，但也不是逐字逐句，也是快读，主要过程是思考作者的用意；第三遍转换成自己的东西，结合自己的实际去验证这些观点，这个过程可能会消耗较多的时间。与前文提到的「看厚->看薄」相比，这种快速阅读的方式其实是「看薄->看厚->看薄」，虽然多了一步，但效率其实是提高了。

这个读书法，与今天我遇到的问题有什么关联呢？关键在于「筛选」上，对于业务状态的筛选，和对于书中内容的筛选其实是相通的。出于严谨，我几乎是想罗列出所有 if…else…，这个动作本身是没有问题的，问题在于列出来之后未进行第二次的筛选，找出那些最有业务价值的状态，也就是我们读书过程中最感兴趣的点，这些才是我们应该倾注时间的。

人们常说，做好最坏的打算，但以最积极的状态去做事。但问题是，罗列所有最坏的可能性的时候，就如同我陷入对于所有状态的判断的情况一样，罗列的过程耗时耗力，而且很容易让人失去信心，打消积极性。那么事情就变成「最坏的打算还没做好，就已经打了退堂鼓了」。

我们在一开始或许就应该放弃「面面俱到」的期望，只列出最大概率发生的情况，做到心中有数，而小概率事件，就等边做的时候边去调整吧。而针对那些大概率事件，就好比我筛选出的那些关键的业务节点，就要回到「看厚」那个环节，一个一个将其实现。这些都想清楚了，真正动手的时间只会占到很小的比例，要不有人说，好的程序员一天可能写不到多少代码量，因为大多数时间都在思考（等编译），想透了敲打键盘如行云流水，想不明白就处处碰壁不得前行。