不，他在算法问题上，和大学教育一样片面。在这方面他是中了大学教育的毒。
不，他在算法问题上，和大学教育一样片面。在这方面他是中了大学教育的毒。
这篇文章和里面的评论说的很好
banq能否在看完回复后评论一下？？
算法代表的是解决问题的能力，尤其是在面对一个全新的，没有现成解法的问题的时候，你能不能自己找出算法？
算法才是一个公司核心竞争力。懂了编译器构造的算法，即使是使用面向过程的语言，也能写出编译器；不懂编译器构造的算法，即使OO，模式再牛，也写不出编译器。世界上懂OO，模式的公司多了，有几个能挑战微软，SUN，Google？
用面向服务的思想做面向对象的软件，是不是有点道貌岸然。
这个社会化大生产是需要分工的，大家该搞算法的搞算法，该做应用的做应用。散了吧。
总结：算法是写出文章的关键，而设计模式只是练了一副好字而已
企业需要我们是什么，我们就应该学什么，不然你就去创业，自己当领导。人就是这样在活着。
[该贴被lei55022033于2009-10-20 23:43修改过]
另外，同样是砌墙不同的工匠砌的墙是不一样的，可以砌出豆腐渣，也可以砌的坚固耐用，甚至砌出了艺术品（个人觉得能坚固耐用就很不错了）。这里砖当然是很重要的（没有砖，没有墙），但是希望不要把砖烧到墙那么大，主要是太费力。当然烧砖的技术要是进步了对墙的质量提升是很有帮助的，要是对这个有兴趣也要发扬，还是挺佩服有人能静下心来做基础，服务大众。不过现在制砖的工艺已经很难提升了（就像CPU的主频），因此现在大家的主要话题是如何砌墙。
举个排序的例子好了，你可能把堆啊，快排啊，希尔啊都研究的很透彻，能根据数据的分布能选择最适合的方法并实现。但站在应用的角度这并不够：考虑到排序是一个普遍的操作，对于不同的场景可能需要选择不同的方法，所以我们需要一个可以自适应又可以扩展的排序框架(这里用framework大了点），这就需要抽取出Comparable接口；进一步，假设User一般比较少，适合bubble sort，而Order很多，用quick sort合适，HotTopic又适合heap sort，这又需要抽取出一个 SortingAlgorithmSpecfiable接口来。
以上过程中，好的架构可以更好的封装算法，为引入新的算法打下了一个良好的基础。而软件开发中，对需求的实现也可以认为是一种算法，并且这种算法是注定会随着对需求的深入理解而改进的。这种情况下，对整个系统来说，组织好实现，通过开闭原则使得改进算法的影响尽可能封闭，其重要性要大于某个具体的算法效率有了多少提升。而这也是模式啊，架构啊所追求的re-usability。
一个比喻，软件就是PC,架构就是主板，算法就是芯片。有一块好的主板，以后可以通过升级CPU啊显卡啊什么的来提升机器性能。但一个差的主板，就是CPU再快，内存再大，还是能天天给你折腾出蓝屏来。