常常反思：
我正在做什么事？ 为什么要做这件事？ 目前是怎么做这件事的？
这件事的实质是什么？ 做好它需要怎样的技能素养？ 怎样才能做得更高效自如？
做一件事有“道”“法”“术”三个层面。 遵循既定的步骤去完成它， 而不深思其中的缘由， 是“术”的层面； 深思这件事的本源、盲点和局限性， 并找到应对的方法， 是“法”的层面； 领悟这件事的运作规律以及与现实世界的关联， 并自觉去遵循它， 是“道”的层面。
做一件事， 常常思考： 为什么要做这件事？ 是否有必要做这件事？ 是变化的环境和业务所导致， 还是原有的设计不具可扩展性， 无法容纳新的事物， 还是原有的设计存在缺陷， 需要修复它在应对新事物出错导致的麻烦？ 如果弄清楚这些问题， 从结果反推初始， 就能看到原有的做事方法还可能导致哪些尚未出现的问题， 也就是从已知推出未知， 而不是遇事解事， 步步踩坑。 当觉察不便时， 要在当下做一些努力， 并详细地记录， 避免以后类似的情况出现， 或者即使出现， 也能以更小的努力去解决。
比如说单元测试， 只是遵循既定循例去编写单元测试， 这只是“术”的层面； 明白单元测试的本源， 是为了有效地保证每一步每一个环节的正确性， 通过保证所有步骤所有环节的严谨与正确性去保证整体的正确性。这是其核心理念和优势， 同时从中也可以推出其盲点和局限性：
（1） 可能可以穷举， 但是耗时耗力。 比如一个功能包含十个步骤， 每个步骤都有成功或失败的几率， 甚至每个步骤可能出现多个错误， 那么单元测试至少要覆盖 1024 种用例， 而实际上这 1024 种用例可能只有少数用例出现比较频繁， 或者只有少数用例具有突出的重要性和重大的影响性，大部分用例在软件生命周期内几乎不会出现； 单元测试应该尽可能覆盖这些频繁使用的、具有突出重要性和重大影响性的用例， 而不是妄图全部覆盖； 或者说， 20% 的单元测试可以解决几乎 90% 的问题； 而 80% 的单元测试只是起到了安慰剂的作用罢了；
（2） 单元测试无法阻止烂代码的产生； 可以写出无比烂的代码去通过单元测试。 这只能通过“CodeReview” 去减轻其危害； 但这足以说明， 单元测试只能验证功能的正确性， 却不能判断功能实现的质量好坏， 不可过重倚赖， 更不可倚赖于几个数字； 数字从来不代表质量， 当质量出现问题时， 好的数字是一种讽刺。
（3） 单元测试无法阻止已有测试用例之外的情况的失败。 单元测试仅能保证已经设计的用例的成功， 但当现实发生的情况是在用例之外时， 就是单元测试力所不及之处。 因此， 要保证已有单元测试用例的有效性和充分性。
（4） 单元测试无法阻止全链路的失败。 当关联的外围系统发生变更时， 即使内部再如何正确， 也无法阻止失败。 这涉及到系统之间的接口协议。
因此， 当单元测试施展其威力到瓶颈之处时， 就必须考虑其他办法来加以完善。 比如一个功能包含十个步骤， ABCDEFGHIJ， 如果仅当 ABCD 全部正确才能推出 E', EFG 全部正确才能推出 G' , HIJ 全部正确才能推出 J' ， 当 E'G'J' 全部正确才能推出功能正确时， 单元测试可以进行划分-分组。 验证 (E'G'J') 的组合共有 8 个； 验证 (ABCD) 组合共有 24 个， 验证 (EFG) 和 (HIJ) 分别有 8 个， 总共只需要 48 个用例即可。 这种方法不完全符合“单元测试”的定义， 但此时正确的做法， 不是质疑做法的正确性， 而是应该质疑定义的合理性， 不是修改作法， 而是修改定义， 使之更具有可行性； 它是基于已有理念和实践上的针对具体情况的一种优化。
其次， 单元测试难以高效地测试多个组件的正确性。 往往一个全链路的集成测试就可以测试很多组件的正确性， 通过单元测试需要使用大量测试用例才能做到。 就好比， 1000 可以等于 1 自加 1000 次， 也可以等于 500 自加 2 次， 尽管后者无法保证每个组件在不同情境下的正确性， 但是在验证正常情境下的正确性的时候无疑是最有效率的。
做事的方法， 从来是不拘泥于既定的循例， 而是想方设法去实现一些特别的方法， 更高效地验证程序的正确性， 发现程序里的 BUG， 甚至有时这种方式显得有点诡异， 但确实是高效的。 唯有这样， 才能突破一些陈规， 充分释放创造力， 去引导软件开发活动。