“业务性需求”：用业务知识建模之后，OO、设计模式和框架用于灵活地（健壮、可维护）实现该需求。战略层面。
用户需求包含上述两种需求，实现两种需求所需建模和实现的知识和经验不同。
约瑟夫问题、公交路线搜索、关键词联想、内存管理、进程控制、图像处理、模式匹配等属于“计算性需求”，追求的是高效率，智能化，代码高度专门化，缺乏响应变化的灵活性。
工作流控制、发帖回帖、报表等属于“业务性需求”，对效率需求不高，基本上是让原来由人做（想）的事情自动化、电子化、无纸化，对效率和智能要求较低。
一般的企业ERP、网站等只需要“业务性需求”。
一般的企业应用（博客、介绍用网站、论坛等），和底层较远，和“应用层”较近。所以只要能实现“业务性需求”就行了。不过不少人干习惯了“业务性需求”，就懒得去学习“计算性需求”的技能了。
框架优化或者创造新框架，需要数学知识建模，尽量抽出不需要变化的部分并高效解决（这属于“计算性需求”）。之所以要抽取不需要变化的部分，就是因为算法高度专门化，缺乏响应变化的灵活性。
顶尖级别的像MS、IBM，成功并不是光靠算法，而是靠“抽出不需要变化的部分并高效解决”的能力。Windows的高层部分，例如注册表、服务管理什么的，其实应该算“业务性需求”。底层部分如内存管理、文件系统、硬件驱动，属于“计算性需求”。
所以MS和IBM不是不重视架构，而是他们还涉及底层。至于先设计底层还是先设计架构，似乎没有什么规定，可以同时进行。
两种需求各有作用。但不可否认，中国软件业很多人都去搞“业务性需求”了，可能是因为好找工作。但“计算性需求”迟早要搞的。
计算性需求是国家的科技，业务性需求是国家的经济。都去当经济学家、企业家，学MBA、EMBA，赚很多钱，的确有助于国家的经济，但不能当成立国之本。美国日本经济强科技强，中东的石油出口国家很有钱，科技一般。国际地位一目了然。
PS:
或许学框架不需要先学算法，但肯定要学数学知识建模方法。
就像程序员不需要知道三角函数和差化积公式，但肯定要知道什么地方要用这个和差化积，怎么用。
学C语言而不学编译基础，例如不理解while(*pszStrA++ = *pszStrB++);为什么是字符串拷贝，永远开发不出高效程序，因为不可能理解都用CACHE的程序为什么一个比另一个低效。如果一个程序员不打算开发高效程序，那他是个好程序员吗？
OO技能和框架使用的门槛比较低，虽然要做到融会贯通也很难，或许比精通算法更难。但注意到Banq认为“大学生不要学面向过程、算法和数据结构，应该直接学OO”，否则“会跳不出来”，这属于危言耸听，认为大学生的“跳出框框”的能力不行。
一个要澄清的部分：会用各种排序、最短路搜索、红黑树等经典算法，并知道这些算法的实现方法，并不算是懂算法，顶多是个学舌鹦鹉。学会这些东西，就像学会使用一个框架的API，一点技术含量都没有。面对一个问题，能够造出自己需要的算法才算算法高手，这一算法肯定是书上没有的。例如一个经典问题，给定一个N * M的矩形墙壁，用1*2的瓷砖去贴，有几种贴法。算法到了高手境界，和架构到了高手境界一样，已经无招胜有招了。就算你没听说某个算法，你也能想出这个算法。
我的感觉：熟悉C++的要转Java很容易（C++也是OO的，也可以培养面向对象思维和设计模式），熟悉Java的要转C++很难。这里Java单指程序设计，不涉及框架API；C++也不包括WindowsAPI和MFC。
原因何在呢？
[该贴被seedjyh于2010-06-03 09:12修改过]