顿悟, 软件的设计

对软件的思考
作为一个软件开发人员, 我, 工作了四年, 入行时间不长, 一直在JAVA领域做项目, 从JSP时代走过, 做过EJB项目, 维护过用procedure写的业务逻辑, 参与了银行系统(比较规范)的开发, 作过系统的售前方案,现在暂作项目管理, 虽然,每个项目都有它特有的行业背景和时代特征, 从一个程序员的角度去看这些项目, 无非让程序员实现起来感觉烦燥或困惑与否, 因为初级程序员的水平来没有这样的感悟能力, 所以, 部分人会选择继续学习, 学习语言的特性, 学习设计(模式), 学习项目架构, 学习操作系统, 学习业务知识等等, 正是这些知识的积累, 程序员开始成长, 变得充实而自信,更多的应对和解决实际问题. 但这些是项目的全部吗? 是否具备了这些知识, 就达到了项目架构师或系统分析师的要求? 现在我的回答: NO.

如何理解设计
那么什么是软件设计, 什么是软件的灵魂, 这是首先要回答的问题. 之前, 我的理解如下, 熟练使用几种设计模式, 软件能够灵活适应业务变更, 软件可以灵活配置, 等等. 虽然能达到这样要求的软件已比较接近答案, 但还没有达到真正设计的高度.

我的回答
基于业务模型(domain model)构建, 采用某种语言实现, 结合具体的框架和容器, 为展示层(view, 不一定有)提供
服务的完整解决方案.

domain model: 是对行业的业务建模, 行业的业务高度抽象和涵盖, 所有业务都可以从些引申, 我称之为项目的core, 这是项目的核心, 行业解决方案的核心, 即神.但, 只有些, 也不能称之为一个项目或框架.
语言/框架/容器(架构层): 这是实现手段,对domain model的实现, 即形. 这里涉及到操作系统, 通讯方式, 持久方案, 服务和流程设计,这里往往被是最容易被人们认为的设计部分,而没有一个完整的domain model作支撑, 这样的设计也不会走太远, 至少, 有一定的限制. 但,如果这个的设计能够被完成, 在业内也是一个不错的软件, 也能做到被人称道.
view: 用户接口, 即外衣.

为什么ror/grails不能被应用到企业开发领域, 很大程序上是由于它不能对domain model的支持, 软件的灵活性是复杂应用条件下, 显得无能为力.现在大部分软件也没有domain model, 更甚将技术架构与view混为一谈, 导致需求的变更引导软件整体变更,不能适应需求的变化.
架构层可以由EJB,SPRING,SOA,等实现,这也只是服务的接出方式,适应技术发展的表现.但架构的核心不应因此改变而改变.

适用范围
以上适用于企业应用和服务性网站的设计.

声明:以人为本人现阶段的认识,有不足和错误之处,请拍砖.在此先谢过各位.

评论

52 楼 kamet521 2008-08-23  

我也在立志做PM

51 楼 honda418 2008-08-22  

google了一下Ror/Grails

长知识了！谢谢

50 楼 black_zerg 2008-08-17  

这兄弟其实就是说要熟悉表，熟悉业务。认为这个就是最重要的。
其实我前面回帖就是这个意思，这种趋向其实是很多的，很多人做了几年程序就觉得老写代码也没前途，想靠这个吃饭了，就因为已经熟悉了表，熟悉了业务，熟悉了当前公司手头的一些项目。就开始和客户谈需求，说说业务，作类似顾问或管理或协调的工作了。我认识的不少优秀程序员都走得这条路。
这样行不行？当然行，作为个人选择当然可以，但个人认为并不是真正的技术道路。特别是，当你进入到不同的领域，你必须有足够的技术底子和应变分析能力，如果你吃惯了你那几张表和陈旧的技术框架，你对自己能够有自信么？
我现在的职务就叫consultant，但我还是把自己看作一个程序员，因为我喜欢技术。 所以当项目中遇到问题，同事就知道给我解决，因为我总能搞定。
但是很遗憾，技术人员多如牛毛，确实不是靠着对技术的一强热情就能怎样怎样。
这个世界也就是乱七八糟。而且其实严格的说，我们都不过是应用领域的一帮混饭吃的。

49 楼 abcx 2008-08-15  

pf_miles 写道

好几条路可以走，长短不一；楼主悟出的这条路不算长；
就围绕domainModel来说了？其实就目前世面上的主流软件产品来看，有多少有影响力的软件是有完整的domainModel的？甚至是domainDriven来开发的？我觉得从历史规律来看，目前国内有影响的系统大都是以数据为中心的，即先有数据模型，再有这些数据模型的内存表示（java代码），并且保守地讲，也只能继续按照这个模型来维护（以数据为中心）；我并不觉得它们差，我当然也不会觉得真正拥有domainModel的软件差，它们都是软件，并且都可以很优秀。

如何理解设计？

说什么domain model，什么设计模式，什么样的架构，有用么？现在还说不到那一步上；先要看你在什么行业里面谈设计；不同的行业就有不同的情况；说实话，我看到此文标题之后，我真没有料到会出现这些词汇，并且还说得这么细致。我预想中应该会给大家讲个故事，或者寓言之类的，启迪软件设计智慧的东西，我觉得“顿悟”者应该讲一个这样的东西。

是否“顿悟”？从上面来看，楼主可能还要继续“悟”；而后对ror/grails的一些说法自有人来解释，就不多说了。

有道理。
我的理解设计与UML，OO，设计模式，domain model无关。设计就是在对行业业务领域，技术（框架也是技术），team成员等深刻理解的情况下，并在成本，预算等约束条件下提出的构建系统的一种路径。好的路径需要有一些创造性的想法，但与GOF模式无关，当然路径好坏的评价标准应视实际情况而定。总之，设计是一个非常务实的工作，到了最后没有人能为你提供指引。

48 楼 isaac 2008-08-14  

lurena 写道

对软件的思考
作为一个软件开发人员, 我, 工作了四年, 入行时间不长, 一直在JAVA领域做项目, 从JSP时代走过, 做过EJB项目, 维护过用procedure写的业务逻辑, 参与了银行系统(比较规范)的开发, 作过系统的售前方案,现在暂作项目管理, 虽然,每个项目都有它特有的行业背景和时代特征, 从一个程序员的角度去看这些项目, 无非让程序员实现起来感觉烦燥或困惑与否, 因为初级程序员的水平来没有这样的感悟能力, 所以, 部分人会选择继续学习, 学习语言的特性, 学习设计(模式), 学习项目架构, 学习操作系统, 学习业务知识等等, 正是这些知识的积累, 程序员开始成长, 变得充实而自信,更多的应对和解决实际问题. 但这些是项目的全部吗? 是否具备了这些知识, 就达到了项目架构师或系统分析师的要求? 现在我的回答: NO.

如何理解设计
那么什么是软件设计, 什么是软件的灵魂, 这是首先要回答的问题. 之前, 我的理解如下, 熟练使用几种设计模式, 软件能够灵活适应业务变更, 软件可以灵活配置, 等等. 虽然能达到这样要求的软件已比较接近答案, 但还没有达到真正设计的高度.

我的回答
基于业务模型(domain model)构建, 采用某种语言实现, 结合具体的框架和容器, 为展示层(view, 不一定有)提供
服务的完整解决方案.

domain model: 是对行业的业务建模, 行业的业务高度抽象和涵盖, 所有业务都可以从些引申, 我称之为项目的core, 这是项目的核心, 行业解决方案的核心, 即神.但, 只有些, 也不能称之为一个项目或框架.
语言/框架/容器(架构层): 这是实现手段,对domain model的实现, 即形. 这里涉及到操作系统, 通讯方式, 持久方案, 服务和流程设计,这里往往被是最容易被人们认为的设计部分,而没有一个完整的domain model作支撑, 这样的设计也不会走太远, 至少, 有一定的限制. 但,如果这个的设计能够被完成, 在业内也是一个不错的软件, 也能做到被人称道.
view: 用户接口, 即外衣.

为什么ror/grails不能被应用到企业开发领域, 很大程序上是由于它不能对domain model的支持, 软件的灵活性是复杂应用条件下, 显得无能为力.现在大部分软件也没有domain model, 更甚将技术架构与view混为一谈, 导致需求的变更引导软件整体变更,不能适应需求的变化.
架构层可以由EJB,SPRING,SOA,等实现,这也只是服务的接出方式,适应技术发展的表现.但架构的核心不应因此改变而改变.

适用范围
以上适用于企业应用和服务性网站的设计.

声明:以人为本人现阶段的认识,有不足和错误之处,请拍砖.在此先谢过各位.

同样楼上个观点。软件的设计先要分析需求，整理业务框架，在业务框架的基础上才是设计业务对象、业务流程，进而设计数据库和具体的技术实现设计，然后才是编码。

47 楼 jerry_hu 2008-08-13  

能帮助到客户是最好的设计
用什么技术,只是忽悠不忽悠的东西

46 楼 youngphy 2008-08-13  

ladofwind 写道

题目倍儿牛B，进来看了，符合楼主工作四年的领悟，共勉，呵呵

!-_-，都什么人这是.

45 楼 bbyyzhang 2008-08-13  

各司其职，分工不同而已。
不管在什么位置，能做好自己要做的事情，你就是成功的，优秀的。
不要妄图做一个什么都会的人。

44 楼 laowang 2008-08-13  

飘过飘过，顿悟还需继续

43 楼 pf_miles 2008-08-13  

好几条路可以走，长短不一；楼主悟出的这条路不算长；
就围绕domainModel来说了？其实就目前世面上的主流软件产品来看，有多少有影响力的软件是有完整的domainModel的？甚至是domainDriven来开发的？我觉得从历史规律来看，目前国内有影响的系统大都是以数据为中心的，即先有数据模型，再有这些数据模型的内存表示（java代码），并且保守地讲，也只能继续按照这个模型来维护（以数据为中心）；我并不觉得它们差，我当然也不会觉得真正拥有domainModel的软件差，它们都是软件，并且都可以很优秀。

如何理解设计？

说什么domain model，什么设计模式，什么样的架构，有用么？现在还说不到那一步上；先要看你在什么行业里面谈设计；不同的行业就有不同的情况；说实话，我看到此文标题之后，我真没有料到会出现这些词汇，并且还说得这么细致。我预想中应该会给大家讲个故事，或者寓言之类的，启迪软件设计智慧的东西，我觉得“顿悟”者应该讲一个这样的东西。

是否“顿悟”？从上面来看，楼主可能还要继续“悟”；而后对ror/grails的一些说法自有人来解释，就不多说了。

42 楼 juedui0769 2008-08-12  

“若无所感，岂有这番说话”
前辈们说得都很有道理。

41 楼 上帝He. 2008-08-12  

暂学 不敢妄言

40 楼 lurena 2008-08-11  

peihexian 写道

题目挺有意境，进来一看，楼主还是脱离不开mvc啊

一直做BS结构的应用, 但对MVC的理解可以从不同的角度考虑.

39 楼 tophappycredit 2008-08-11  

<div class='quote_title'>black_zerg 写道</div>
<div class='quote_div'>吹吧，说实话我觉得管理人员确实很重要，但真正聪明人多数不乐意干，乏味。你以为你知道几张表是干嘛的就是懂软件设计了？软件设计应重于技术能力和分析能力，所以一个真正优秀的设计者可以立足於完全不同的情况，知道怎么去分析去给出方案，并有驾驭所需技术的能力。不是说你就知道点现成行业背景知道大概有什么流程就得了。我早年做过sap顾问之类，那些哥么更逗，一破表什么意思他都不会跟你说的，跟宝贝似的藏着。还有工作过的一个地方也逗，那破程序年久失修，啥文档没有，就几个遗留程序员知道大概怎么回事了，那个对知识的珍惜哟。 国内也就这个风气，干几年程序员再往下干，别人都看不起你，我一哥么就老和我说：不好意思啊最近不怎么做技术了，忙啊，哈哈。所以个人取向不一样，我觉得也没什么，但别没事就贬人家。别的不说给你一个全新项目你自己搞你搞的定么。 </div>
<p><br/>  其实工作了对工作环境是相当重要的，如果同事之间能够互相交流自己的心得，在软件项目开发中经常沟通，而不是埋个头自个写代码而不跟同team的member讨论，大概这个团队就失去了一半的力量了，而对项目经理首先要对这个项目要有通盘的考虑，做好project planning  and control，这才是至关重要的。总之公司的氛围很重要，如果在一个团队中大家不注重sharing,互相猜忌，那项目没法做了。</p>

38 楼 ninjajie 2008-08-11  

[FLY]好[/FLY]

37 楼 peihexian 2008-08-11  

题目挺有意境，进来一看，楼主还是脱离不开mvc啊

36 楼 狂放不羁 2008-08-10  

软件设计更多的讲究艺术，是一种艺术的活动。

35 楼 duker 2008-08-10  

楼主总结的有点片面..
这些只是"应用软件" 领域一个很小的分支..题目有点大..

34 楼 lurena 2008-08-10  

allenny 写道

顿悟过后，该干啥还得干啥

事情还是原来的事， 但方法会不同，考虑的方面会更全面。

33 楼 hank31713 2008-08-10  

感觉有点抽象，还是继续努力学习吧。。