论业务领域知识比掌握技术更重要(从建模贴子切分出来)

我觉得这样的讨论是很有益处的。虽然可能有时候与最初的论题越跑越远，但是显然这些问题都是大家做软件设计过程中最关心的问题。
方向其实是很重要的，方向正确可以使人少走很多弯路。不过讨论最好还是具体一些，泛泛地谈说服力不强。说“对象建模就是好来就是好”或者“数据建模就是好来就是好”都象是脑白金的广告。从讨论过程中我们看到很少有人完全使用对象建模或者完全使用数据建模，potian 也不是完全否定数据建模，他也是结合了对象建模和关系建模（叫“关系建模”好象比叫“数据建模”更准确些）的优点，不过以对象建模为主。要采用 AOP 方式做开发没有很好的对象模型是不可能的。

我的学习方法就是孔夫子说的“多闻阙疑。慎言其馀。则寡尤。多见阙殆。慎行其馀。则寡悔。言寡尤，行寡悔，禄在其中矣。”这段话虽然很功利，但是我认为是正确的学习方法。
还有讨论问题要讲究一些讨论技巧，比如 shenli 兄问：
"企业级应用系统"?ofbiz是无所不包的吗?至少他没有涉及的领域必然就有比它做得好的
其实 Quake 也从来没有说过 Ofbiz 是无所不包的，他只是在自己开发的业务领域发现 Ofbiz 是一个非常有用的框架，所以很自然地喜欢上了这个框架。他喜欢这个框架值得争论吗？呵呵。

框架的开发是非常辛苦的事情，虽然我们现在已经有了很多好用的框架，但是我们中国人是否只要用这些老外的框架就足够了呢？我们在用别人的框架的时候，实际上脏活累活别人都帮你做好了。但是要想开发出自己的框架还是应该多关注一些低层技术的实现。面向对象离不开低层数据结构+算法的支持，一个好的算法和一个普通的算法性能能够差 10 倍以上，你说算法值不值得关心？低层甚至还会用到一些与操作系统和编译原理有关的技术。比如以前曾经讨论过的服务器端反向控制（IOC）模式，很难说它是直接来自于对象建模，它更有可能是来自于操作系统的一些设计思想。

《计算机程序设计艺术》是经典中的经典，我们应该都读一读。我并不认为讨论数据结构+算法只是程序员的事情。好的设计人员和 PM 对这些知识必须掌握得非常深入才行。《人月神话》中说，设计人员在作出设计后必须提供一条可行的实现途径，但是他只是提供参考而不是要求程序员必须这样做。设计人员完全不考虑实现细节在 OO 的天空中任意遨游当然是很理想的状态，但是真正做起来却是困难重重。

这个线索的标题：论业务领域知识比掌握技术更重要，其实也只是相对的。从程序员发展的角度，同时熟悉业务领域的知识（domain knowledge）显然更加有利于他的发展。但是好的程序员是否就一定要向 PM 的方向发展？或者说做了 PM 是否就可以不关心技术，只做做咨询或者顾问？我对这两个问题的答案都是否定的。
一个好的程序员做了 PM，从此不再研究技术，不再关心具体的实现，这意味着他的职业生涯的终结。国外管咨询这一行的知识叫做灰发知识，意思是说你已经不再有创造力，你贩卖的都是你以前获得的经验。就象 TDM 所说 CMM 所有的成功经验都是上世纪 80 年代获得的。那么我们现在还有必要关心这个明显落后于时代的 CMM 吗？
一个合格的 PM 至少要身兼 3 个角色，对于客户他是技术专家，帮助客户使用技术手段解决各种业务问题。对于程序员他是业务专家，帮助程序员理解客户的需求，与程序员一道做设计。做好各种辅助工作（建立和维护开发环境，寻找适合的开发工具），便于程序员以最高的效率完成工作。PM 其实起到的是一个业务知识与技术知识之间的桥梁作用（很多公司并没有 PreSales 这个职位，因此 PreSales 的工作其实是由 PM 来担任的）。同时 PM 还是一个管理者和督导者，要以最有效率的方式组合各种资源，合理安排进度、计划和目标，按时交付具有一定质量保证的产品。
项目开发的目标是实现客户的业务需求，对象建模和数据建模以哪个为主要具体问题具体分析，这只是实现目标的手段。在这方面我同意 Quake 的意见。

同意你的意见，不过我认为这些不属于domain knowledge范畴，这些都是作为程序员所应掌握的技能，而不管开发什么项目，用什么方式。
我对domain knowledge的理解更狭窄一下，集中于用户的业务，以及“这些不同业务领域共性的理解（人员，组织，权限）”这些方面的知识。而且我认为这些共性的东西也因为具体应用的不同而不同，尤其是现状。

我的看法是，专职做pm和做咨询实际上已经意味着转行了，技术变得不再是最重要的，而管理知识和专业知识变的更为重要了。
最后，我觉得dlee把pm的职责扩大了，不知道老板会不会因为这样而为你加薪。

其实这 3  个角色是一个 PM 必须要做到的，否则就不可能顺利地完成项目。PM 要做的事情比较杂，不同于专业的设计人员和开发人员。PM 在项目中所起到的作用和这里的斑竹起到的作用相同。moderator，金山词霸中翻译为缓和剂，PM 就是整个机器正常运转的润滑剂。PM 和设计师、程序员只有分工的不同，没有什么贵贱之分。
这个讨论还是告一段落吧，呵呵。估计大家都已经没有什么兴趣了。我们还是应该多关注一些有趣的话题。比如 Color UML、AOP，etc.

关于上面说到的基础知识我再补充一些证据：
Ofbiz 中的 MiniLang （一种基于 XML 的轻量级语言）所用到的技术属于编译原理的范畴，它并不是 OOAD 的产物。

中国的软件业为什么不如国外？中国的理论专家并不缺，中国的理论专家完全可以把某种新的软件理论研究透彻，然后指出其中的缺点123，说的头头是道。但是真正涉及到实现并且遇到了一些复杂的技术难题时就大眼瞪小眼不吭声了。实现真的是没有创造性的低级工作吗？我佩服国外的一些大师是因为他们不仅仅是理论的大师，而且都是实践的大师。Peter Coad 如果没有丰富的实践经验和精湛的技术，就不可能提出 Color UML 和 FDD，而更有可能走 Grady Booch 的道路成为一个惟过程论者。

在 potian 的网站上看到 potian 的一段话：

看来 potian 也是非常重视这些低层技术的，只是因为他已经掌握得很好了，所以现在更关注的是对象建模和 AOP 等问题。但是普通的开发者如果不多关注一些低层技术，在某些场合试图完全用对象建模来解决问题是要走弯路的。有些复杂的问题（就是我以前提到的使用稀疏距阵和向量计算才能解决的问题）完全使用对象建模来解决也许有可能，但是肯定不直观而且会绕很多弯路。对象建模解决的是软件的结构问题，不要试图用它来解决不属于结构方面的问题。

    我酸一句：此言差矣

   "对象建模解决的是软件的结构问题", 这句话问题多多。

   一般说，我们认为框架解决软件结构问题。

   IMO,对象建模不过是以对象描述业务世界的事物。

   "但是肯定不直观而且会绕很多弯路",此言我也不同意，对象建模的目的就是为了更直观，至于是否走弯路，那就看你对事物的理解足够透彻否。

   一点浅见，但愿不贻笑大方。

业务与技术，永远的话题
我的观点是：
什么是程序设计？一种契约，一个规范
契约，规范目的是为了将一个领域的问题(业务)，通过某种方式转化为另一个领域（计算机－>技术）的问题
两者无所谓哪个更重要，当技术成熟时（技术问题得到较好解决），业务更重要－－大部份的数据库应用
当技术不成熟时（特殊问题，主要是数学方面的了），那业务理解得再好也实现不了

两者的发展从来都不是同步的，整个行业就这样螺旋式的发展着，互相促进着对方发展

作为程序员，技术压倒一切；作为系统设计者，业务方面要重要一些，所以，没有技术背景的设计者是不可想象的

其实程序员再精通业务业不可能比行业人员精通，程序员要的是将行业人员转换成为技术表述的能力

一个契约，一个规范无法转化完全，那就多建立几个，程序员的体系不就是这样建立起来的吗？