首页 > 代码库 > 关于解题的思路与方法

关于解题的思路与方法

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



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


先说说解体思路。

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


自上而下:

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


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

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

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

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


自下而上:

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


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

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

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


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


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


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



其次,列一下解题方法:


分解法:把大问题拆分为多个小问题,逐一求解 

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

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

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


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

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

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

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

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

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

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


例:

(1)C语言循环章节的经典题目:小球落地又弹起

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


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

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

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


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

使用前提条件:有穷性

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

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


枚举发/穷举法:

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

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


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


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




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


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

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


关于解题的思路与方法