如果需要，尽可能实践。
但是实践之后出来的结果单凭经验和直觉往往具有迷惑性。
看到一个大牛带着一个有了好几年编程经验的程序员验证解决一个程序运行缓慢问题的文章，文中有三个验证程序，程序a运行了几分钟才结束，而且显示有严重的内存泄露，程序b只是在程序a的基础上增加了一行内存回收的代码，结果程序b运行几秒钟就结束了，程序员凭经验就简单地认为程序结束时没有释放内存相关，但是检查了半天都不知道根本问题出在哪里。大牛不置可否，又设计了一个程序c，把所有内存释放操作集中在最后，结果程序c像程序a一样运行过程异常缓慢。由此推断：程序运行快慢跟内存泄露关系不大。
大牛问程序员在测试程序里分配内存记录里所使用的算法，程序员回答用的是一个二叉树。二叉树比单纯的有序链表插入，删除内存分配记录更高效。理想状态下二叉查找树效率远比线性链表遍历查找高，处理1000000个元素，链表需要对所有元素进行500000次操作，二叉查找树的效率则是对数级别，只需处理20个元素，对比一下两者效率高下一目了然。不过这只是理想状态。大牛之后又问了一个深入症结的问题：有没有对二叉树进行平衡处理？程序员回答：为什么要做平衡处理？这样会使代码更复杂了。这些都是书本上的知识，程序员回答没有错。但现实情况却超出理论状态，而事实上就是因为这棵树的实际形态右顷到接近线性链的状态。二叉树右倾到接近线性链表的状态，这属于小概率事件，而程序员没有对检测程序使用的二叉树算法做平衡处理，使得实际的二叉查找树遍历查找速度反而还不如链表遍历查找，导致程序运行异常缓慢。
找到症结修改测试程序后，重新运行上面三个程序，三个程序运行的速度又恢复到理想状态，而且差别已经没有以前那么大了。
这个例子很有启发：单纯的知识和经验都不那么可靠，反而会成为你寻求问题症结的绊脚石。
