一个复杂的问题涉及到比较多的模块，每个模块都具有相当的复杂度，
模块之间也具有相当的复杂度。首先要将问题涉及的模块理出来，当
你要分析一个较大的层面时，就将这个层面下涉及到模块用语言描述
出来，使你自己能够统筹处理这几个模块之间的关系。当我们在看一
个证明时这比较容易，当然对于本身具有较高复杂度的问题，就是看
懂也不是轻易而举的事情。我比较关注的是，当你面对的问题不是别
人呈现给你的一个比较有条理的解决方案，而是完全没有方向的时候
怎么办？我们可以通过理解别人解决这个问题的过程，看当他面对的是一个完全茫然的问题时，怎样划分自己思路的，然后
再依自己的思考写出来，这样就能积累到比较多解决问题的经验了。大家肯定都有这样的经验，当你对一个问题已经有了思
路，然后顺着思路你希望顺利成章的将问题解出来，然而之后你却碰到了钉子，发现解决的范围太大了，或者太小了，已经
走出了好远，诸多的努力貌似是白费了似的。有一种办法可以避免这种脑力资源的浪费，就是在你十分十分清楚问题的范围
之后，再去想解决方案，十分确定之后再去想。但是，这同样会让你觉得进度很慢，因为这相当于在问题的范围研究理清它
的各个复杂度层面。

这样，我们就提出了一个更有价值的问题，在问题复杂度研究到怎么样清楚的情况下就开始解决方案的研究？
而且，我有这样一个断言，答案其实总是蕴藏于问题之中。