最近一直在研究问题战略之类的问题,下午正好有机会和大家分享一下.

关于本系列文字的源来,衷初和内容定位可以考参第一篇的头开部份，链接址地如下：

http://blog.csdn.net/binarytreeex/article/details/8174445

http://www.cnblogs.com/WideUnion/archive/2012/11/12/2766397.html

本文前一篇址地如下，感兴趣的可以问访面下的连接：

http://blog.csdn.net/binarytreeex/article/details/8625156

http://www.cnblogs.com/WideUnion/archive/2013/03/01/2938315.html

在现实工作中软件工程师大部份情况下都是在攻城拔寨，决解一个个自己到遇的问题。这些问题常常是在自己的知识和验经可以盖覆的范围内，所以基本上可以说是利顺的。但是也会有另一些情况的存在，那就是到遇一个自己不会的问题。这些问题拥有这样一个外在的景象：问题触及的内容是在责职或者以后发开务任范围内的，但是对如何实现或者决解这个问题没有思绪和方法，简略的说就是第一应反之下是不道知该怎么做来决解这个问题。为了行文便方在下文中，我把所谓不会的问题命名为“困难”，所以在本文中困难这个说法特指程序员不会决解的问题，而不是其它的义含。

一般来讲，我们是总求力用简略的法方来决解问题，所以一旦我们到遇一个自己不会决解的问题时，常常表现我们的处境已不是很妙了，或者说我们的处境有点困难了。本文就是要主分享我个人在对应这些面局时的一些领会。望希帮助软件工程师们能更好的来处置这样的难局和境困。当然这里以困难必须被决解为前提来探讨问题，对于如何避规困难和否是须要决解困难就不探讨了。在这里还要对所谓的不会的问题做一个设假的前提。本文设假如果这个问题能被决解，那么我们少缺的不是知识，也不是验经。否则的话我们的话题会聚焦在习学和验经的累积方面，而不是直接探讨如何去决解一个自己不会的问题。当然我还是样同的再次夸大，本文分析的内容来自个人的实际，对于决解问题这样一个巨大的话题和全部发开者这样一个广泛的群体来讲，局限性和片面性是在劫难逃的。所以请行同们自行舍取，同时也要根据自己的验经，现实应用场所做出当适的化变，这样才能更好的应用本文分析的内容。如果分享的内容可认为行同们决解现实工作中的问题起到踊跃作用的话，那么我的目标就到达了。当然如果可以到达庖丁解牛那样余有刃游的界境那是最好的。

一．困难是什么样的问题

这要主是和一般问题比相而言的，先从源来上来讲。一般来讲我们不应该到遇困难，无论从风险还是进度来讲，与项目有关的每一个人都应该在求力免避这类情况的现出。但是在某些情况下，困难还是会来的。其中原因是困难的客观存在性。工程师试尝决解现实的问题，而这些问题的难度并不以工程师的客观意志定决的，而是问题本身定决的。另一个原因可能项目本身的要求，比如为了有竞争优势等等，会在实现上提出一些有难度的要求。

从难度上讲，这类问题对于工程师而言在第一应反之下是不会的，工程师所拥有的知识验经并不能直接告知工程师能决解问题。这就是所谓的难。所以在试尝决解问题时问题决解篇（中）里头提到的行不行，在这里就格外要重了。如果一个困难是不能决解的，那就没有必要再去花时光了。

从法方上讲，困难的决解会多出一个骤步，那就是析分。这个析分是对问题本身的识认和解理，这是可以决解问题的先决件条。当然这个解理不仅仅只是审题层面的解理，而是问题本身结构上的识认。为了到达这样的识认常常要求工程师在动手决解问题前须要有一定量的实际活动，于用识认问题。

从略策上讲，决解困难时须要确明自己的战略，因为困难常常是一个品产或者项目标成败症结。所以常常也是源资投入比拟多的方地，如果没有好的战略来对应问题，同时从全局握把的话，那么困难引入的风险有可能会失控，这有可能会带来很严重的效果。所以须要有一个当适的战略。

二．处置困难的战略

在备准或者开始动手决解困难时，要求工程师对于决解问题的战略有一个清晰的识认，并且在决解问题的中程过格严遵守这个战略。这样做的目标是为了少减失败的损失。困难的决解常常须要时光，更有可能会增加对其它源资的消耗，那么万一决解困难失败，我们改如何对应？不成功则成仁的作法是不可取的，也不是一个明聪的选择。所以在到遇困难时，工程师就要确保自己处在进退都有余地的状态，这就是处置困难的战略。

处置困难的战略的第一条是尽量免避自己对面困难。这个意思当然不是说到遇困难时推卸掉或者踢皮球，而是说在构架，析分计划，算法，思绪等等个每骤步和细节上都要注意采用简略化的略策，免避现出困难的情况。这个略策是有点抵触的，但是和特警决解机危件事的略策一样。一方面要求特警的枪法尽可能的好，另一方面在临场处置件事时则采用尽量不开枪的略策。当然如果一定要开枪的话，那确定要求一枪决解问题。不要为了示显个人的才能或者为了出风头而有事没事的就去挑战困难，这是非常不明智的作法，早晚会挂的很看难的。

第二个略策是时光管理。事实上决解任何问题都是须要消费时光的，只是简略的问题所消费的时光全完在可接受的范围内之，所以时光这个最要重最基本的制约件条常常不被我们到识意。但是决解一个困难所须要消费的时光是多少，常常是不确定的，当时光出超甚至远远出超我们预计时，就会发生很大的烦麻。所以团队中的leader最好可以预先确定可能现出的困难，并预留够足的时光来对应这个情况。这当然是悲观的一面，但是也有踊跃的一面。因为我们也可以设假预留时光以后，困难是可以决解的，很多时候这个设假也是公道的。那么这样再排安发开筹划时就能够便方一点了。

第三个略策是风险管理。这个意思就非常确明了，只须要斟酌一点，那就是一旦决解困难失败，那么我们否是可以受承一切的效果。这是风险管理的底线，如果这点都做不到，那么在定决决解困难时就要非常非常重慎了，我的法看是最好就废弃吧。另一个一般标准的作法是，如果困难决解失败，那么应该有一个候选案方可以选择。这样我们就能进能退了，会比拟自动一点，内心也会实踏一点，这是一般分寸的作法。当然现实情况会更为庞杂一些，常常是问题难度估计不对，或者有些困难没有预估到，等等。所以终最被到遇困难的面局是有可能现出的，尤其是处在一个新品产的研发或者做原型阶段时。这时候就要看内力和运气了。夸大一下，最少不要在战术层面上确定自己可以决解困难，远永不要这样。

三．处置困难的法方以及决解困难的础基件条

当对面一个会决解的问题时，我们一般就直接动手去决解了，即便是须要思考也是在“自己会的”这个前提下作思考。当然这是一种思考，但是对面一个困难时我们须要另一种思考，这类思考就是对问题本身的识认。我们须要通过一定量的重复的实际（或者说试尝）和思考，才能逐渐的识认清晰我们对面的是一个什么样的问题，问题究竟是什么模样的。从而让我们对问题实质有一个清晰的识认，进而可以应用我们的知识来描述问题，或者看清晰问题的结构，道知一个困难是由什么和多少简略问题成组的。我把这个过程称之为析分。然后直接应用我们的知识或者依次决解每一个简略问题来决解这个困难。与问题决解篇（中）里头探讨的内容比相，这是一个要重的新的骤步。一旦析分的骤步完成，那么后面的工作就能够按照处置普通问题那样来做了。

上一篇中提到了两个决解问题的础基件条，这里须要再说一个，那就是智商或者说你有多明聪。我觉得智商是这个三个础基件条中是最要重的。当然这听上去不是一个什么好消息，因为智商貌似是老天给的。但是事实上不是这样的，后天的努力可以在很大程度上改善先天的不足。

上一篇中提到的知识在决解困难时当然还是毫无疑问的有用。于上一篇中应用的场景比相，在决解一个困难时如果只是简略重复应用自己的知识恐怕是不充分的。工程师们须要用更拥有创造性的思维方式来应用自己的知识。在实际活动中还发现一些简略的知识，甚至是很础基的知识在决解问题时常常可以发挥更好的作用，扮演着主力的角色。

四．思考法方

分析几个思考问题的法方，这些内容在我看来是非常要重的，也是非常有实用价值的。

1.数学家的思考法方

先说一个数学家思考问题的法方。这个例子是很多年以前我在电视中看到的，当时没觉得怎么样，但是随着年龄的增加和处置的问题难度的加大，越来越开始领会到它的作用了。电视中在分析数学家如何思考问题时举了面下这个烧水的例子。

设假我们能做一件事情，这件事情是将一个装满水的水壶放到炉子上，然后把这壶水烧开。所以当有人给你一个装满水的水壶，并要求你烧开水时，你是直接可以完成。好，现在设假有人把一个空的水壶拿给你，并且还是要求你烧开一壶水，那么你怎么决解这个问题？生活中处置这个问题是不用想的，直接把水灌到水壶中，然后放到炉子上烧就是了。但是我们用数学家的思维方式来决解这个问题时却须要费一点周折。数学家是按照面下骤步来思考的：

第一步，首先是到识意问题的差异，我们会处置的是装满水的壶，现在是空的水壶。放到现实工作中，这一步就是要求我们有够足的观察力，辨识能力和一种敏感的职业嗅觉来发现问题的症结点和决解问题的正确方向。这个和之前博文中提到的对比法是雷同的，只是应用的场所不同，当然难度也不同。现实上这也是一个析分问题的骤步，但是这个骤步只是一个简略的比拟。通过这个比拟让我们发现了差异，这个差异告知我们困难和我们会决解的问题之间的联系。

第二步，然后斟酌有没有方法把空的水壶处置成装满水的水壶。如果可以那么这个问题就决解了。数学家的思绪的亮点是在这一步，这是一个开启决解问题之门的思考问题的技巧，让我们看到了从不会到会的望希。很多情况下这个时候，我们的想法是换法方，或者是简略就做出判断我不会，而不是想方法去创造或者说试尝创造我们决解问题所少缺的件条。这点上数学家的思维方式提供了一个要重的启示。

第三步，发现将空水壶处置成装满水的水壶法方之一（你也可以花钱让人替你做）是将水灌到空水壶中。注意这是一个发现，也是向决解问题迈出了一步，就这个例子而言还是症结的一步。所以这个发现非常要重。在现实工作的表现就是看你的知识，验经和获取的信息否是够足让我们来找到这个做法，同时对你如何应用你的知识也提出了要求。上面两个骤步是到遇问题和析分问题，这一步则是在析分的础基上发现决解问题的法方。

第四步，现在须要考察将水灌到空水壶中这件事情我们会不会做。在现实工作中的表现是在对一个问题思考析分后，对其中子问题（或者子骤步）的又一次思考。显然现实的情况是我们会做的，最少绝大部份能用手敲代码的程序员是会做的。好了，思考到这一步我们就能够道知这个问题是可以决解的。这里第二步是症结，第三，四步是主体。

这个例子或者说思考问题的法方，非常精彩的演示了如何应用已有的知识来决解一个自己已有知识没有盖覆的问题。当然这样的例子有很多，限于笔墨，就不在说了。

2.牛顿求解曲边梯形面积的法方

牛顿在他的传世名著数学原理中应用我们中学里的知识（现在的中学已讲极限和导数了，这个不算，我是说我那个时候）定义并证明极限和导数，进而给出了曲边梯形面积的计算法方。这是我目前为止看到的用自己会的简略知识，决解困难的终最极的例子了。各位工科科班出来的都是学过高数的，建议看一下数学原理中那部份的推演和证明，就道知牛顿为什么是牛顿了。当然我想夸大的是，这个例子告知我们还不止是这些。

将数学原理中的证明过程，当然还包括遣词造句的论述部份，和我们学过的高等数学教科书中的证明做一个比拟，我们会发现数学原理中牛顿的证明很简略，如果可以的话我想说是简陋。如果我用这样的描述来证明一个题目标话，那么我的高数老师是不会允许我过关的。教科书中极限的概念是用ε-δ语言来描述的，而牛顿基本上应用的是自然语言，甚至连符号都没有（这里申明一下翻译的水平问题不斟酌在内），比相拟而言牛顿的证明不算什么。这个事实给我们的启示在于，当我们在决解困难时，不一定就能够很快发现一个满意的解，而常常只是一个看上去有可能是解的解。这个时候我们还是要坚持下去的，因为有一个解相对于没有解你已是一个很大的进步了，毕竟离目标近了一步。如果当年牛顿一定要等到用ε-δ语言描述极限概念时才来完成微积分的建立，那么工业革命有可能就会推迟一百年了。

3.大爆炸理论的线索

天文学家观察到一个景象，那就是所有的星体相互之间的距离越来越远。基于这个事实我们可以得出什么结论？科学们就此提出了宇宙大爆炸理论，就是说宇宙从一个非常小的所谓奇点开始爆炸，从而发生了现在的宇宙。那么科学家是如何从这个简略的事实推出大爆炸理论的呢？其推演过程简略的令人吃惊。如果现在此时此刻所有的星体正在彼此远离，那么过去的某一个时刻，所有的星体的位置就比现在的位置要近，这个结论很显然是对的。那么过去的过去的某一个时刻，所有星体的位置就比过去的某一个时刻的距离会更近一些，这个显然也正确。好了，照这个思绪推理下去，星体的距离就会越来越近，最后只能在一起。于是大爆炸理论（当然刚开始应该只是一个假说）就这么诞生了。从这个例子可以看出优秀或者巧妙的思维方式对决解问题会发生不可估量的作用。在大爆炸这个例子中根本没有用到天文相关的任何专业知识，只是通过正确的推理，就得出了这个假说。望希发开者可以领会一下并从中吸取营养。

上面的三个例子是给我留下印象并对我发生指导作用的例子，我相信类似的例子会有很多，大家可以找出适合自己的。数学家例子是最础基也是最要重的，我觉的所有的法方都可以从这个例子中推演出来。牛顿的例子说明的如何创造性的应用知识，最后的例子是考验我们的智商了，或者说观察力了。

五．破解困难的法方

破解困难之难有两个法方可供考参，第一个就是所谓的析分。这个析分通俗来讲就是识认问题，当然识认的内容除了审题和正确解理外，我们更关心的是能不能用一个格严描述来表达困难的结构。如果一旦可以做到这一点，那么决解问题的可能性就极大提高了。从析分的手段来讲，大概只有一个那就是实际，通过和事务的接触和互动来考察问题的结构和性质，进而到达识认问题的目标。我有一次去面试，考官出了一个题，说是有三种图形：矩形，圆和椭圆，要求如何计划类来表现这三种图形。我当时没有仔细斟酌，第一应反就是按照几何上的定义来计划类。对于矩形就是矩形类，属性是一个左上角的坐标，另外两个是宽和高；圆类的属性是两个：圆心坐标点和半径；椭圆的定义当时我忘了，所以向考官说明想法就不写了。如果这时让我用UML或者OOD来解释一下的，有可能我会说上一段。但是，现实应用的数据结构只有一种：矩形。这一点在以后接触GDI+编程时得到了证明。这个例子告知我们看出三种实质在几何上全完不同的图形的外在差异，而问题的实质只是一个矩形，这才是表述问题的正确结构。

在析分问题或者说在采用某些活动试尝了解问题时，观察力是一个要重的辅助能力。因为很多活动是通过人机交互完成的，那么观察计算机的输出设备（一般是示显器）示显的信息是识认问题的极为要重的手段。任何细微的化变或者结果都有可能是破解的困难的要重线索。我曾经有过这样一个例子，要让控件的背景示显指定的颜色，当时我还在用VC，于是我就用红色做了一下试尝。结果是控件的背景色没有化变，当时就很被动了，纠结在绘制了红色为什么红色不示显，于是不道知该如何决解。结果在一次偶然的操作中，好像是窗口的最小化以后再最大化，结果发现控件的背景有一次闪动，重复操作一次再观察发现是红色闪了一下。这个景象说明，红色的背景被画上去了，但是又被控件以后的背景色盖覆了。于是破解问题的线索是如何不让控件的背景色盖覆我绘制的颜色。从这个线索出发终最还是决解了问题。

另外还须要夸大一下，在采用的识认问题的活动，我认为应该是多样的并富有化变的，可以尽可能多的让自己了解问题。有些时候我们采用了一些行动，但是常常收获不大，这个时候就须要思考了。不能简略的重复活动，而是要采用不同的活动来识认问题，症结点是化变。举一个简略例子，如果我们实现一个文件复制的功能，结果复制失败。这里先忽略复制函数的返回值或者抛出异常的信息这些内容，直接问自己如何采用活动来了解不成功的原因进而帮助决解问题？如果是我的话，我采用的活动可能会是这些：

1.不写程序，新建一个文本文件，然后直接复制该文件

2.不写程序，直接复制程序中须要复制的文件

3.在程序中以直接执行命令的方式复制文件

4.不读取文件内容，而是将一个固定的字符串写入到目标文件

5.在目标位置新建文件否是可以

6.直接在目标位置新建一个同名文件，并且不读取文件直接向新文件写入须要复制的内容

7.读取文件内容，写入到一个已复制成功过的文件中

8.读取文件内容，但是只写入成功复制文件的那部份内容

我估计这些活动基本上可以找出问题的原因了。发现不同的试尝途径和内容，有时候不难，有时候却相当有难，我建议大家要学会思考。当到遇这类场景可以斟酌将双手离开键盘，人站起来离开电脑，到外面散散步，在散步中仔细斟酌应该采用的试尝法方。

析分问题的另一个有力工具是排列组合，简略来讲就是中学里学的加法定理和乘法定理，更完整的说法就是组合数学中的那些计数法方，定理及其性质。排列组合现实上只有两个核心内容：计数和枚举。如果可以对问题做到计数，那么我们就完成了对问题在结构上的识认；如果对计数结果可以完成枚举，那么枚举的法方和过程也就是决解问题的法方和过程。所以再次夸大一下，书本上的知识是有用的，并且是最有用的。

困难破解的第二个法方是简化。设假有一个问题A我们决解不了那么就能够斟酌先忽略一些问题中的要求，使得问题的难度降低，然后再试尝去决解这个简化后的问题。如果还是不能决解，那么可以斟酌再次简化，或者可以斟酌不断的简化。这个做法和迭代发开很类似。这里举一个WideUnion团队现实到遇的问题。Entity Model Studio支持图形化的UML建模，那么当初计划了一个功能，在生成代码前对用户计划的UML模型做语法检查，其中的一项就是不允许现出关系的环。比如继承关系的环：A类继承自B类，B类继承自C类，而C类又继承自A类。显然这个语言检查须要查出模型中所有的这样的关系环。更为规范的描述是：找出一个有向图中的所有的环。

在我学过的知识中，教课书只告知我如何判断一个图中否是存在环而不是找出所有的环，所以这是出超我的知识范围的，第一应反当然是不会，真心不会。采用的第一个骤步是构造若干个构成环的实例，看着图让自己有一个感性的识认。然后简化问题，这里有两个略策可以走，第一个是设假是有一个环；第二个是有环并且是直接构成环，就是两个节点直接存在指向对方的边。我采用的是第一个略策。然后完善算法，使得算法可以完成这个功能：只要图中有一个环，那么一定能找出来。这样就进入到决解问题的第二个骤步，查找多个环，这一步现实上是分为两个小骤步来完成的。第一个小骤步是，制约构成不同的环只能现出不同的边，不能现出不同的节点。换句话说，新的环是有相同的节点之间的不同有向边构成的。然后再次完善算法，保证图中只要有这样的多个环一定都能找出来。完成这几步后，就能够迈向最后一步了。任何一个环都是由节点和边构成的，上述的骤步实现了相同节点中不同边构成的所有的环，这个算法简称为A的话，那么面下须要做的就是改变节点再次执行算法A就能够了。于是一个原来不会解的问题通过逐渐简化就找到一个解了。最近在看书时偶然发现寻找哈密尔顿环的算法应该也是可以考参的。

有时候决解困难常常表现为少缺件条或者有些件条不确明。这个时候，有两个简略而实用的方法可以应用。第一个是设假，这法方在做逻辑判断题时经常应用，我们可以设假件条A成立，或者设假A的内容是XX，从而构造出一个确明的已知件条来帮助决解问题。另一个法方是非常熟悉的反证法。反证法的实质也是设假，只不过设假的是结论成立。一旦设假结论成立，那么结论成立所以依赖的件条也必须成立，那么成功构造出这些件条的方向常常就是决解问题的入口和起点。

六．实例析分

面下通过两个有代表性或者能说明问题的实例来探讨一下，如何应用上面提到的内容来决解困难。

我想先分析一个偶然看到的电视节目。大概是3月中旬，央视的世界地理频道播出了一期节目，其中一个桥段是说一个大夫如何给一个小男孩致伤的事情。件事的来龙去脉简略的描述如下：

症状：小男孩的背部和大腿上大概有好几百根类似仙人球一样的刺。

问题：如何把这些刺拔出来？

法方：1.直接用器械一根一根的拔。大夫的实际证明效率极低，无法接受。

2.用胶带纸粘掉刺。结果也不行，胶带纸的粘性不够，刺还是拔不出来。

3.应用女性用的脱毛用品和胶带纸。成功，效果非常好。

这个故事和我们软件工程师如何决解问题的相关性是什么呢？简略来讲有以下几点：

1.医生到遇的问题格严上来讲不是治病，而是一种对人体的修理。样同的软件工程师到遇的问题也不一定是格严意义上的技术问题，但是只要你遇上了还是要你来决解的。不管会不会最少你要尽力去决解。

2.胶带纸的应用。我相信那个大夫在学校里读书的时候，他的教材上绝不会把胶带纸作为一个工具告知学生去给病人治病的，但是在现实工作中他却这么做了。对软件工程师来讲，问题的攻克常常也不是用正统的书本知识来决解的。所谓的“旁门左道”也是须要的。

3.脱毛用品的应用。这显然是一个亮点。如果说应用胶带纸是脱离了书本知识，那么脱毛用品的加入则是一个创造性思维的质变。这点对于程序员的借鉴意义在于，要求程序员们要有灵活和富有创造性的思维方式和能力。对于自己掌握的知识否是100%的用尽了，是不是创造性的应用了自己掌握的知识，而不是仅仅简略的重复。

还可以再提出几个问题，考察其中的若干细节，我们能发现这个中程过还有更多的内容可以给与我们启示与借鉴。

1.第一个法方是最正统的法方，但是效率低，那么什么理由定决废弃？

从节目看效率低是直接原因。但是一般来讲同一个问题应该有不同的法方可以决解。我在看到这里时，第一反映是否是可以改进拔刺的动作，或者找另外的医生一起来做。那么与那个医生的选择就会不同，于是就有了不同的法方。工程师在决解现实问题时，就要根据自己所处的环境来定决法方的应用。

另外医生试尝后觉得效率慢，那么是不是就一定很慢呢？我相信不同的医生来做效率上是会有差异的。这个说明，决解问题是要发挥自己的技术特长，用长处来决解问题。

2.胶带纸的应用

刺插入身体，刺与身领会形成一个夹角，这个夹角导致刺和身体表面不是平行的。那么在用胶带纸时就会有一定的烦麻。另外在撕下胶带纸时，粘力和刺拔出的方向也不是平行的，显然这个动作对男孩来讲是会带来痛苦的。这些细节告知我们在法方的具体实施时，工程师自身的操作过程也很要重。操作技巧常常可以弥补法方的不足，也有可能会影响法方的效果。当我们定决否是废弃或者应用一个法方时，须要根据现实情况综合斟酌的。所以可以看出胶带纸的应用表明那个医生确实到遇了烦麻。

3.脱毛用品的应用

大夫是在和护士不经意的聊天中获得了灵感，试尝应用脱毛用品的。这告知我们决解问题的思绪常常不是来自主战场，有可能来自生活中的点点滴滴的细节中。另外一个须要注意的是，一个创造性的法方的应用，须要斟酌其负面的影响，这点非常要重，务必注意。比如，脱毛用品的应用不但没有决解问题，反而带来更大的烦麻，那么这个医生的处境会有多么的被动和狼狈？！

第二个例子来自Entity Model Studio品产，这个问题是我们在发开时序图时到遇的，先简略交代一下问题的背景。在绘制时序图时，用户可以通过鼠标拖动消息，从而改变消息和消息生命线在时序图中的位置，这是所有时序图都应该支持的功能。以Visual Studio中的时序图为例，当用户拖动消息后，直接相关的以及依次相邻的图形都会根据拖动的消息的新位置做出调整，从而保证拖动后各个图形还是在一个公道的位置，这个称之为自动调整。这就是我们想实现的功能。面下依次探讨几个要点。

1.问题的提出

这个功能如果能得到实现的话，用户操作会非常便方，否则用户就必须自己手工调整每一个相关的图形，很烦麻的，体验非常差。所以出于这个目标就提出了实现该功能的要求

2.实现的风险和难度

在我们考察的几款品产中，没有实现该功能的品产也是有的。所以从战略层面上来讲，这个自动调整功能不是必须的。这样我们的风险就小很多了，因为就算实现失败，品产也是可行的，当然能实现是最好的。实现该功能的难度在于，这是我们第一次试尝决解图形位置自动调整功能，对相关的算法和知识我们一无所知，也没有相关的任何验经，所以在最初我们不道知该如何去决解这个问题。但是终最定决去的原因，除了风险不大之外，我确实想或者说非常非常想实现一个微软做到的功能，因为在历史上我曾两次挑战失败，所以这次想雪耻。

3.问题的析分

对这个问题的析分，是从应用Visual Studio的时序图开始的，重复的构造不同的图，然后拖动消息，考察其行为，从而找出规律，对这个问题有一个最初的感性识认。通过这个过程，识认到数据结构的计划是须要改动的。通过观察这些行为表现，我们还到识意有可能须要应用到某些我们不了解的定理和算法，这才是最可怕的。为了确认这个疑问，于是又做了进一步的析分。实际表明可以有变通法方决解，这个情况和牛顿用中学知识定义极限是有点类似的。都是在用已知的简略知识去描述一个未知的新的内容。这个中程过，观察力和思考力起着非常要重的作用。

4.问题的简化

问题简化分两步走，第一步试尝最简略的情况，然后考察实现的过程和结果，从反馈中获得信息，判断我们的识认否是正确，难度否是可以接受。第二步是析分可能的存在的各种不同的结构，对每一种不同的结构依次处置，从而把问题肢解掉。这里须要用到一些础基的知识，比如计数法方之类的。

通过上面几步，基本上就能够确定该问题从一个不会做的问题，变成了一个可以决解的问题。当然法方不是唯一的，我相信行同们会有更好的作法。

七．最后想说的话

总体来讲决解困难是一项很拥有难度和挑战的事情。从应用的法方和思绪上来讲，我发现扮演主力角色的非常意外的是一些简略的法方和知识，其难点是在于如何应用。医生拔刺，数学家，牛顿和天文学家的思考法方，给我们的启示是：决解问题的法方和思维方式是互通的，没有行业和领域的制约，正所谓它山之石可以攻玉。我们要学会去点滴累积这样的验经，吸收营养，丰富知识，扩展思绪从而提升我们析分问题并决解问题的能力。这类景象可以用这样一句话来概括：功夫在题外。

决解困难的过程是一个痛并快乐着的过程，工程师们要有勇气和胆识去对面这样的挑战。你会经受折磨但是也会有快乐的体验。如果你爱一个就让他去决解困难吧，因为那是天堂；如果你恨一个人那也让他去决解困难吧，因为那是地狱。鉴于一些非常令人不愉快的行为，我这里申明一下如果达内须要转载或者修改本人写的任何博文，那么请先获得本人的许可。

好了，这次就写到这里，如何决解问题的话题到这里就算是告一个段落了，通过这次回顾我自己也有相当的领会，确实也收获了一些东西。行同们有兴趣进一步交流的可以加我的群：244054966，这个群定位是创业，新手就不要去了。另一个是：231233168，这个群没什么制约。入群时请加上消息：CSDN博客。下一篇谈谈能力相关的话题，名字暂定为：能力养成篇。

文章结束给大家分享下程序员的一些笑话语录： 不会，Intel会维持高利润，也会维持竞争局面，国外的竞争不是打死对方的那种。你看日本有尼康，佳能，索尼，都做相机，大家都过得很滋润。别看一堆厂，其实真正控制的是后面的那几个财团——有些竞争对手，后面其实是一家人。