言之有理！我们总是在感叹我们struts不会，hibernate不会，什么框架出来，你就什么都不会。我们会了又怎么样，这些框架也好比工具，你会了这些工具就跟工厂里的工人的一样了，这只能让中国的软件普及，而不能让软件科学进步。如果要使软件业有发展的话，那就是去设计框架，框架的设计的好坏就源于你算法和数据结构的精通程度，就如一个高端仪器工具需要精细的零件。
我根本不赞成Coolyu0916的两个观点
1 Coolyu0916也承认搞oo框架和搞算法是不同的分工，但他显然有一种算法优越感，认为搞算法就高人一等，我觉得这种偏见十分错误。先入为主认为自己擅长的东西高级，把别人视为低等，不是一个成熟的IT人应持的态度。
2 Coolyu0916认为数据库和os就是单纯的算法和数据结构，这点我是万万不能苟同的，windowsXP那样复杂的体系结构难道仅仅是算法，我想还是框架设计为主吧，当然它比一般企业应用要更注重算法。至于数据库更不仅仅是一个算法问题，你一个算法专家去搞数据库，可能吗？数据库和os有着比企业应用更为复杂的体系结构，虽然早期数据库和os开发使用的是面向过程的语言，但框架设计这一关是回避不了的，决不因过程式语言就成了纯算法，那么多的功能有机集成在一起，而且有提供给用户扩充的接口，没有一个好的框架，行吗？
我个人认为，数据库和os可以看作是一个企业应用，算法只是其中的一个部分，只不过它更加成熟，而且产品化，经过千锤百炼，适应了几乎所有企业。
我见过国外一家大公司的一个电子书浏览器的源码，纯C写的，50万行，30个人搞了1年。我们要参考它作一个java版的，单单听他们给我讲解软件架构就讲了3天。其中称得上算法的，依我看只有一个加解密模块。纯C算过程式语言吧，能说只有算法吗？
我认为只要是做软件，不管什么语言，除非你要做一个演示小程序，否则都是架构设计为主，算法为辅。至于谁高级低级的问题，只能看谁有垄断权。只有一个合格架构师，非它不可，那他就nb。同样，只有一个搞算法的，那他身价必然倍增，有两个的话，就递减了。
碰到算法问题，就两样了，三维空间物体旋转后的位置计算、消隐计算，我轻松搞定，他们怎么也不能理解，一位老兄看了我的代码后，摇摇说“你还是杀了吧”。
虽然在公司，别人无法替代我，但我也总想在架构设计方面做出突破。花了几年的功夫，spring、struts、webLogic应该说也懂得了不少，但付出的时间代价太大，我总疑惑他们怎么那么轻松就拿下来了。我也单独负责开发了几个项目，但自己清楚，太大的不行，都是中小项目。
说到底，架构设计也是难度很大的。你从中科院或者名大学里拉出一群算法专家来，改行搞框架，他们还真不一定行！
冯·诺依曼模型至今为止还是构成计算机的基本模型。这种模型的基本立足点就是指令+数据，指令处理数据，也就是通常所说的过程式思维。过程式思维就能导致指令不能重用么？就能导致难以扩展难以修改？宏指令集，子程序，不都是重用的表现？“对象组合”在本质上不也是追求一个统一的、递归的责任体？如果换成OO模型，你会怎么设计计算机的基本模型呢？你的对象运用得再彻底，领域建模（说实话这里的领域实体除了运算器，控制器，存储器和I/O系统，还能有什么？）再厉害，最终在某个地方（也许是你在对象模型里建模成领域服务），你还是要对数据进行加减乘除之类的基本运算，而这些运算，本质上还是过程范式，表现出来的还是算法。
我的观点是，侧重OO跟侧重算法并没有冲突，两者非平行，而是正交互补的关系。
再就是大家在做java项目的课程中，周围人包括很有经验的老师等等人的建议很多都是——数据库很重要，数据库设计一定要在所有设计前最先出来。即便采用hibernate的时候，也是现有数据库设计，后有反向工程的映射文件和java类。
而第一个java web稍微完整些的程序，是数据库课程设计中完成的，数据库设计成了其中的重头。
对于软件领域的知识体系问题，最近进行了很多自我的总结思考，碰巧今天又发现了这个帖子。关于软件和数学的关系问题——有一门叫做《计算理论》的课程，是国外CS专业的很重要的一门课，国内CS专业基本不怎么开这门课了——从我的自身体验来看，这门课比较难学，但是真正帮助我们从数学的角度来理解计算机方面的种种。比如大名鼎鼎的church-turing理论，计算机和算法已经被进行了数学的抽象，图灵机模型和算法其实是一一对应的关系。怎么说呢，按照个人的理解，觉得数学这个抽象的工具某种意义上还是很practical，在软件领域有着不可磨灭的作用。
不过，以本人目前的理解能力，觉得oo和数学不是排斥的关系，大概，oo从宏观上组织软件结构……
数据库方面，本人正处于严重困惑中，开发系统时数据持久化和数据库是怎么一回事儿，顺序问题，本人正在痛苦的摸索中。
然后，我想，之所以很多程序员不能把注意力放在业务领域这一块，而是被java中各种技术冲昏了后，可能除了因为大家思维转变的原因，还有一个重要原因是……怎么说呢，大概缺乏一个实现的架构，又对那些角色的程序员那么容易使用。以自己的感受来说，一个开发团队中采用了某种大家不熟悉的开源框架，那么似乎每个成员都必须花时间去了解熟悉它。其实大家的学习能力，还有完全清晰的分工协助情况，实际情况下总不很那么理想化的。是大家代码功底不够？设计模式思想缺乏？学习速度有限？还是别的原因呢？
以上是做为一个大三刚结束的本科生一些看法，包括一些疑惑