1、每个人都是从自己的工作经验出发，来总结的。所以，从我的经验来说，我的工作中需要算法的情况，的确是非常少。

2、hurricane1026做的网格计算；dreamhead做的XRuby，应该都是算法密集型的软件吧。

3、我先大而化之的论一下，软件至少可以像企业分为资金密集型、劳动力密集型一样，分为：算法密集型；业务逻辑密集型；使用体验密集型；他们面临的挑战是不同的。
算法密集型，典型的比如一个搜索引擎。
业务逻辑密集型，典型的比如一个ERP。
使用体验密集型，典型的比如一个全Flash站点。

4、任何软件，归根结底自然是数据结构、算法、逻辑这些东西。但是，我们做实际的项目，不是从根子上去做，而是从已有的基础上去做。
一个拿着榔头的人，看到任何问题都觉得可以把它作为钉子敲一敲。
而一个拿着锯子的人呢？

5、说实话，我的算法功底的确是不行，但是我也可以很负责的说，我的debug能力非常强。那么，当遇到一个问题的时候，我往往会第一时间想到用debug的办法来研究。
这既是我的长处，同时也会成为我的盲区。

6、hurricane1026你在算法方面下过苦功夫，因此，你在面试的时候，很自然的就会问人家算法方面的问题，而且，当人家不能回答那些“很简单”的问题时，你就认为他们不行了。

那么，反过来问一个问题：一个人要来你这里面试，你认为，他不知道，或者忘记了哪些东西，是可以接受的呢？

在我看来，如果他忘记的答案，能够借助电脑、网络，在五分钟内把答案再找回来的。那都不是要紧的知识。

7、上一次讨论应届生的问题时，我很强调完成任务的能力。交给你一个任务，如果这个任务需要你具备算法知识，那就去掌握算法知识。如果这个任务需要你具备debug的能力，那就去提高debug的能力。如果这个任务需要你....，那么，就想办法积累xxx方面的能力。

任他千难万险，我总能够搞定。才这是真的厉害了。

8、回过头来说学校阶段，摆在你面前的那些课程，无论他是否重要，无论你是否喜欢，搞定他。挂掉任何一门，都不算本事。至于通过之后，那些知识还是不是需要记在脑子里，我看也就不必了。更多精彩讨论，请看：http://www.javaeye.com/topic/65655

hurricane1026问到：我问的难么？
这个帖子，我就不跟了，说说自己的看法：

1、无论是做软件，还是任何其他行业，甚至包括做人，很多时候，都是在解决问题。遇到麻烦，想办法解决。

2、最简单的问题，就是能够在书上找到现成答案的问题。比如：哪种排序的效率更高。

3、如果一个问题，书上没有现成的答案，能够通过Google、查找相关论文等等手段，找到答案的，也是简单问题。

4、如果，搜索不到现成答案，但是能够找到询问的人，问出答案来。比如Google不到，只能到论坛来求人，哀告，冒着被隐藏的危险提出问题。无论当事人觉得如何困难，其实都是小Case。

5、如果无论如何都找不到答案，怎么办？自己找呀！比如，这是一个开放源代码的项目，那就看代码。如果源代码都不开放，那就Hacking。反编译、debug、单步跟踪、设断点、打log，用尽一切办法，找到答案。

6、有很多问题，根本就是左右为难，你也知道了整个困难的全貌。然后怎么去解决他呢？左思右想，反复权衡，尽可能找到最好的方案。甚至如果有创意的话，能够想到一个两全其美的解决方案。

7、更加困难的问题是：它根本就没有正确答案，没有最优解。连如何评价各种解决方案的好坏，都说不清楚。怎么办？你还是得做出决策，然后执行。

8、再进一步，它本来就没有问题。但是，一个原本已经解决了的问题，你现在来考虑，有没有可能存在更好方案。比如：新的切入点；新的框架；新的语言；新的开发模型。这就更加困难了。

不再把人的问题牵涉进去了，那是没底的。

那么，算法算老几？

　　前段时间我写了一篇blog，叫做《小游戏，大道理》。是关于一个叫做“ColorLinez”的小游戏的。虽 然表面上是总结的游戏策略，而我心里一直在琢磨的，还是开发管理的事情。这回《程序员》杂志向我约稿关于项目管理的经验，我就想到拿这篇文章来做基础，谈 谈我对软件开发风险管理的看法。

　　这个ColorLinez，是一个非常简单的游戏。通过移动小球，连成5个以上的一排直线或斜线，就可以消去。每次移动一个小球，如果没有消球，电脑就会再向棋盘投入三个小球。等到棋盘被铺满，则游戏结束。

　　令我相当沮丧的是，这么简单的一个游戏，我却始终玩不好。为什么呢？我开始带着思考去玩这个游戏，一边玩，一边总结，越是总结，就越是发现，这些道理与风险管理中的道理，大有相通之处。

　　1、不要过多的猜测
　　电脑每次向棋盘中投入三个颜色的小球，可能颜色相同，也可能各不相同。我们能够知道的，只有一点：下一次投向棋盘的，将是哪三个颜色的球。我们无法判断再下一次的小球，任何过多的猜测，都是错误的。

　　从开发管理来说，我们能够获知的，只能是目前用户所提出的各项需求。我们无法猜测，用户下一次会提出什么需求。 也许有人会说，我们可以做计划呀，不是有“长期、中期、短期”诸如此类的计划么？问题在于，大多是开发计划，都一定会改变。越是长时段的开发计划，越是有 可能变动得面目全非。猜测和提前准备，最不坏的结果是：“做了无用功”。更糟糕的可能是：“当初花了多少时间去走的歪路，还要再花那么多时间走回来，才能 继续前进。”

　　所谓“KISS”原则，讲的就是这个道理。如果有人希望通过预测需求的变动，以减小风险，那就是缘木求鱼了。

　　2、过多的依赖，往往会失败。
　　 玩ColorLinez的时候，往往会出现环环相扣的情况，如果我能够消掉左边的红色的五个球，就能够继续消掉被红色球挡住的蓝色球，进而再消掉被蓝色球堵的黄色球......这要的局面，除非运气非常好，一般都会死得很难看。

　　在源代码的层次，我们把这种情况，称之为依赖，一个函数依赖于另一个函数，一个类依赖于另一个类，一个模块依赖于另一个模块。一个项目中的代码依赖情况越是复杂混乱，这个项目失败的可能性就越大。

　　再上升一层，说开发管理。当我布置一个任务给“小王”，然后这个任务其实仅仅靠“小王”并不能够完成，在我或者 知道，或者不知道的情况下，他需要寻求“小张”的部分帮助。而“小张”在这个事情上，还不能自作主张，他还要先问问“大林”对这个方案的意见。而“大林” 觉得，这个问题，最好和新来的一个做兼职的同事商量一下。而这个做兼职的同事，是通过email和我们联系的，过来一趟不容易。

　　我以为这个任务的工期，是由我给“小王”布置的。到后来发现事情拖了很长时间都没有完成，才知道原来这个任务背后有这么复杂的依赖关系。正确的解决办法是，一开始就搞清楚这个任务究竟和多少人有关系？然后想办法集中起来沟通协调，然后分头进行，齐头并进。

　　再上升一层来看这个问题，这其实是风险管理的一个重要组成部分。开发中的各个环节之间的依赖关系，如果过于繁杂，就会包含巨大的风险。要化解这样的风险，及时理顺关系，促进有效沟通，是非常必要的手段。

　　3、要给自己留下退路
　　ColorLinez的电脑算法，相当恶 毒。我猜他是这么干的，估计你的目的，然后伺机堵死。面对这种风险，你不能假设电脑是仁慈的，或者赌自己足够幸运。千万不要赌，十赌九输。正如前面所说 的，不要猜测。但是，却可以通过合理的移动，使得接下来投入棋盘的小球，总不会制造灾难。这就是留有退路。

　　再说软件开发管理中的风险管理，我们无法预测需求的变动，我们能够控制的，只是这个开发团队。那么，要减小风险，其实就是两个办法：一个是上面讲的，不要给自己制造风险。另一个就是，通过合理的调度、安排，以缓冲或者规避，需求变动可能带来的风险。

　　更加直接一点，就是说，在制定项目计划的时候，一定不能只做乐观估计，更不能天真的相信，一切都会顺利。必须考虑各种可能的风险，并且为这些风险，留出合理的缓冲时间和后备资源。发现一种方案行不通时，一定要尽快另谋出路。

　　4、小心，再小心一些
　　ColorLinez，是一个完全没有时 间限制的游戏，每一步你都可以思考无限长的时间。但是，一旦移动了小球，就无法再后悔了。往往会出现这样的情况，一步走错，满盘皆输。漏看、点错、突然的 乐观、一时兴起、思维定式等等，都会把你带向深渊。大好的局面，一下子就不可收拾了。

　　软件开发管理，就更难了，一方面，工期要求向来是越快越好，容不得你拖拖拉拉，细细想来。另一方面，又和游戏一样，不能悔棋。如果公司经得起折腾、吞得下苦果、信得过你，也许会再给你一次机会。但是......很难......

　　风险管理，最为重要、也是最困难的一点，是具备足够的风险意识。这个风险意识，还不是简单的，知道有多少风险， 然后就去防范它。首先要有大局观，能够常常关注全局的风险，而不是局限于自己的思维定式。要始终理性的思考和判断，而不是受一时一事的影响。要养成良好的 工作习惯，以避免忙中出错。要常常自我反省，以便更好的改进管理方法。

　　总之，要慎之又慎，以免一失足成千古恨。道理就是那么简单的道理，要始终记得去防范风险，就难了。所谓知易行难，正是这个意思。