很多学生问我这个问题，拿来一道题（或实际一个问题）解决它的思路和方法是什么. 其实人的思维是最难描述的。每个人的思考方式和习惯都不尽相同，解决同一个问题达到同一个效果的方式也是如此。简单的讲，“思路”是难以给出一个单一模式的，但是前人还是总结了很多方法。下面列出我个人比较常用的解题方法和思路，供大家参考。

博文首发地址：http://blog.csdn.net/duzixi

先说说解体思路。

解体思路有两大基本套路：一个是“自上而下”，另一个是“自下而上”。

自上而下：

简单的说，“自上而下”就是先把问题从整体上考虑好，明确整个问题都分成那几个大的部分，每个部分之间的关系是什么，然后再逐层细化和实现。

这种套路适用于以下几种场景：

这类问题基本上做过类似的，对应该包含哪些部分比较确定

一个项目由多人来完成，需要事先做好一定的分工

问题组成部分的关系相对简单

自下而上：

“自下而上”和“自上而下”相反，就是先把具体的局部做好，然后再建立他们之间的关系，搭建起来，用于形成一个整体。

第二种套路适用的场景如下：

 问题未知成分很多，解决起来很迷茫

问题组成部分的关系很复杂，一时理不清头绪

有些问题未知性很强，这种未知性可能是对于个体的，也可能是对于整个人类的。无论怎样，当一件事情很不确定不知怎么去做的时候，不妨就着手先把能做的会做的部分事先了，有时思路也就随着这些实现的部分一点点打开了。在初学阶段（编程语言经验累计未满一年），想把一个较复杂的问题全想好再动手是不可能的。干想不动手是让你停滞不前的首要天敌。

在学习新知识的阶段，最不能害怕的就是做错和走弯路。

其实这两种套路也不是二选一那么单纯，在一些实际问题里，你会发现两种思路是相互配合着的。如何选，如何配合，因人而异。

其次，列一下解题方法：

分解法：把大问题拆分为多个小问题，逐一求解 

分解法是工程师们最爱使用的方法。尤其是工程对象（对于软件工程师来说就是一个软件）相对庞大和复杂的时候，就必须用“分解法”将其分解成几个部分。

如果是面向过程的编程方法，就需要按功能分解成几个模块，然后用函数来实现这些模块。再按解决问题的顺序和步骤依次调用。

如果是面向对象的编程方法，就需要按类进行封装，用方法逐一实现类的行为，然后对外提供接口供其它类调用。

画图法：将问题形象化在纸面上，腾出更多的大脑内存来思考

这个方法是小学数学奥赛宋老师传授的，至今受用。她说画图法可以解决绝大多数问题。那个时候特别喜欢画画，所以也就特别喜欢用这个方法来解决问题。

画图法可以让问题“一目了然”。如果一个人更习惯于形象思维，那么这个方法会非常奏效。

图可以表达自然语言所难以描绘的内容。

软件开发中有很多成熟的“XX图”模式，流程图，类图，更能分解图，页面跳转图等等辅助开发。

但是画图法的功效绝不限于此，你完全可以用自己设计的图来描述一个问题。

如果图画的足够准确，那么它甚至可以帮你完成计算。

例：

（1）C语言循环章节的经典题目：小球落地又弹起

（2）我自己在做蜂窝布局这样的和视觉相关很高的算法的时候，就是事先先用自动铅笔在纸上大体想好计算公式，然后再用代码编写调试。

剥离法：先实现最核心的功能，再逐一完善

初学者在做项目开发时，经常会遇到这样一个尴尬问题：很多辅助功能都实现的很好了，最后发现核心功能实现不了。

从软件工程的角度，这个方法可能更像“原型法”。先实现最基本最核心的内容，然后其它内容再逐步完善。

试探法：“实践是验证真理的唯一标准”

使用前提条件：有穷性

适用情形：缺乏相关文档，文档说明不清，理解不充分

例如：直接看头文件，猜用途，根据参数和返回值类型使用，观察

枚举发/穷举法：

是什么让穷举变得轻松加愉快？——循环

是什么让计算机轻松战胜人类？——循环

对于简单的结构（单一的数组、字典、集合），穷举只需运用一个循环语句就可以搞定。而数组、字典、集合的嵌套对应的就用多个嵌套循环语句搞定即可。

对于稍微复杂一点的结构，例如树，就需要通过深搜或广搜来遍历。

除了套路和方法之外，我个人最喜欢用的思维方式是点展示思维，灵感在知识网络中闪现与穿梭的感觉最棒了。

最后用一句话暂时草草的结束这篇博文：

“这个世上本没有思路，思的人多了，便成了路。”

关于解题的思路与方法