顿悟, 软件的设计

对软件的思考
作为一个软件开发人员, 我, 工作了四年, 入行时间不长, 一直在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,等实现,这也只是服务的接出方式,适应技术发展的表现.但架构的核心不应因此改变而改变.

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

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

评论

32 楼 xiaopao 2008-08-10  

<div class='quote_title'>andy54321 写道</div>
<div class='quote_div'>
<div class='quote_title'>lz726 写道</div>
<div class='quote_div'>用软的方式,思考硬的世界,并抽象出来就叫软件的设计.</div>
<p><br/>这个说法很有道理<img src='../../../../../../images/smiles/icon_idea.gif' alt=''/></p>
</div>
<p><br/>貌似很有道理的说。</p>

31 楼 sai619 2008-08-09  

<div class='quote_title'>lz726 写道</div>
<div class='quote_div'>用软的方式,思考硬的世界,并抽象出来就叫软件的设计.</div>
<p>这句我喜欢</p>

30 楼 fangshun 2008-08-09  

我的最近对软件设计的领悟：不是让设计者将实现方式一字一句的填鸭式教会开发者，而是让他们能在你设计的指导和约束下尽情的发挥！并且设计者在对开发者的协助中，找到设计与实现的障碍，精化设计，增强系统的伸缩力！

29 楼 allenny 2008-08-08  

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

28 楼 jonyzhu 2008-08-08  

gaoran2008 写道

模式只不过是干活的方式。系统设计－－－对需求和技术的熟悉，两者的兼容。

呵呵，同感！

27 楼 Joo 2008-08-07  

neo_q 写道

有句话是这样子说的，分析和设计就是：do right thing 和 do thing right.
这句话很短但是很经典。
所谓的分析这里就是说在领域中寻找到相关的问题域的内容（business或者domain），这个理论上来讲也可以认为是一个建模的过程。
而设计呢？其实他从整个软件过程来看，其实已经是属于实现级别的事情了，也就是对问题域给出的解域。
设计现在分的比较细的话，有架构设计（overall）和具体的软件设计(concrete),架构设计自然是架构师来做的，那么具体的程序设计可能就是由程序设计师来做的，这里可以看到分工的侧重点，架构师掌控整个项目的问题，而设计师在具体的某一部分下功夫。
那么为什么要设计？或者反过来说不做设计又会有什么结果？其实设计就是为了解决现实世界中（问题域）的复杂度，因为我们的软件总是只能模拟现实世界，无法真正替换现实世界，要尽可能地贴近真实世界的首要问题就是如何面对复杂度。比较常规的做法就是分而治之，那么在这里设计的价值就体现出来了，如何分？这就是设计，也就是do thing right.
就像说你要去一个地方，我们都知道走直线是最近的方案，那么这就是一个设计（这就是do thing right），如果你偏要走个三角形虽然也能达到结果但是时间无疑就多了，可是在真实情况下是不是一定能走直线呢？不一定要根据具体的情况来判断，而且会从多个方面来影响你的最终决定，比如花费，为了节约时间你可以“打飞的”，但是成本是不是高了点，虽然时间最短，但是可能你会选坐汽车，这这个角度来说，做设计其实是在多个影响因素中做balance。比如分层架构是不错给你带来很多好处，但是你是否就可以随意多分几个层呢？层太多是否会影响你的效率和开发模式？这些都是balance的因素，也就是说他会影响你的设计。
设计模式是什么也就是说我们面对复杂度的时候有很多已经形成固定习惯的几种解决方案这就是设计模式。低耦合高内聚其实也是面对复杂度的一种模式，所以做设计就是对复杂度的一种分解方案，分解得越好那么软件就越灵活越健壮。
不管是低耦合高内聚还是分层架构还是设计模式解决其实都是分解复杂度的过程中的一些被人们总结出来的套路。

说的都不错，但你究竟要表达什么？

26 楼 towjzhou 2008-08-07  

amonlei 写道

lurena 写道

为什么ror/grails不能被应用到企业开发领域, 很大程序上是由于它不能对domain model的支持, 软件的灵活性是复杂应用条件下, 显得无能为力.

这个这么说？不敢苟同。。。

因为这丫根本不知道什么是domain model。相反在ror兴起前java方面对domain model的实践普遍不如ror。

25 楼 neo_q 2008-08-07  

有句话是这样子说的，分析和设计就是：do right thing 和 do thing right.
这句话很短但是很经典。
所谓的分析这里就是说在领域中寻找到相关的问题域的内容（business或者domain），这个理论上来讲也可以认为是一个建模的过程。
而设计呢？其实他从整个软件过程来看，其实已经是属于实现级别的事情了，也就是对问题域给出的解域。
设计现在分的比较细的话，有架构设计（overall）和具体的软件设计(concrete),架构设计自然是架构师来做的，那么具体的程序设计可能就是由程序设计师来做的，这里可以看到分工的侧重点，架构师掌控整个项目的问题，而设计师在具体的某一部分下功夫。
那么为什么要设计？或者反过来说不做设计又会有什么结果？其实设计就是为了解决现实世界中（问题域）的复杂度，因为我们的软件总是只能模拟现实世界，无法真正替换现实世界，要尽可能地贴近真实世界的首要问题就是如何面对复杂度。比较常规的做法就是分而治之，那么在这里设计的价值就体现出来了，如何分？这就是设计，也就是do thing right.
就像说你要去一个地方，我们都知道走直线是最近的方案，那么这就是一个设计（这就是do thing right），如果你偏要走个三角形虽然也能达到结果但是时间无疑就多了，可是在真实情况下是不是一定能走直线呢？不一定要根据具体的情况来判断，而且会从多个方面来影响你的最终决定，比如花费，为了节约时间你可以“打飞的”，但是成本是不是高了点，虽然时间最短，但是可能你会选坐汽车，这这个角度来说，做设计其实是在多个影响因素中做balance。比如分层架构是不错给你带来很多好处，但是你是否就可以随意多分几个层呢？层太多是否会影响你的效率和开发模式？这些都是balance的因素，也就是说他会影响你的设计。
设计模式是什么也就是说我们面对复杂度的时候有很多已经形成固定习惯的几种解决方案这就是设计模式。低耦合高内聚其实也是面对复杂度的一种模式，所以做设计就是对复杂度的一种分解方案，分解得越好那么软件就越灵活越健壮。
不管是低耦合高内聚还是分层架构还是设计模式解决其实都是分解复杂度的过程中的一些被人们总结出来的套路。

24 楼 Joo 2008-08-07  

以XP的观点,呵呵最近对XP有点上瘾, 以XP的观点,不用预设太多模式,好的模式会在渐进式重构中自动浮现出来

23 楼 leobluewing 2008-08-07  

3年左右的经验吧 跟过3个项目。

领悟的东西就是: 用户变更无处不在。

作为设计人员必须的要求：

1.各种模式一定要熟练，不是说模式是万能药，但是模式至少可以未雨绸缪的提前给变更找好台阶下。
2.责任心。 重中之重，客户可以不专心和你讲业务，但是系统架构者必须事无巨细的了解业务。 责任心三字说白了是职业素养。否则程序员会在背后骂你娘的。

22 楼 lurena 2008-08-07  

zenny 写道

lurena 写道

举个例了

？
楼主是否用五笔打字？
水贴，删了我吧！

呵呵, 是五笔, 以后注意.

21 楼 lurena 2008-08-07  

<div class='quote_title'>mazzystar 写道</div>
<div class='quote_div'>
<div class='quote_title'>hetylei 写道</div>
<div class='quote_div'>一个合格项目经理应该是此项目所涉及的行业专家 而不在乎于他的技术水平 所谓的企业应用，企业信息化建设最重要的还是提供合理的业务解决方案 而不仅仅是“信息化”</div>
<p><br/>确实需要一个行业专家来提供合理的业务需求，业务解决方案，但这个人不一定是项目经理</p>
</div>
<p><br/>一个项目确实需要行业专家, 但一定不是项目经理, 项目经理应该是个多面手, 懂客户, 懂需求, 懂技术, 懂关系. 在真的项目中, 不仅要有行业专家(建模), 还要有系统系统师(偏软)和系统架架师(偏硬), 还有的群小兵,项目经理就是粘合剂.</p>

20 楼 andy54321 2008-08-07  

<div class='quote_title'>lz726 写道</div>
<div class='quote_div'>用软的方式,思考硬的世界,并抽象出来就叫软件的设计.</div>
<p><br/>这个说法很有道理<img src='../../../../../../images/smiles/icon_idea.gif' alt=''/></p>

19 楼 amonlei 2008-08-07  

lurena 写道

为什么ror/grails不能被应用到企业开发领域, 很大程序上是由于它不能对domain model的支持, 软件的灵活性是复杂应用条件下, 显得无能为力.

这个这么说？不敢苟同。。。

18 楼 java菜菜鸟 2008-08-07  

<div class='quote_title'>black_zerg 写道</div>
<div class='quote_div'>吹吧，说实话我觉得管理人员确实很重要，但真正聪明人多数不乐意干，乏味。你以为你知道几张表是干嘛的就是懂软件设计了？软件设计应重于技术能力和分析能力，所以一个真正优秀的设计者可以立足於完全不同的情况，知道怎么去分析去给出方案，并有驾驭所需技术的能力。不是说你就知道点现成行业背景知道大概有什么流程就得了。我早年做过sap顾问之类，那些哥么更逗，一破表什么意思他都不会跟你说的，跟宝贝似的藏着。还有工作过的一个地方也逗，那破程序年久失修，啥文档没有，就几个遗留程序员知道大概怎么回事了，那个对知识的珍惜哟。 国内也就这个风气，干几年程序员再往下干，别人都看不起你，我一哥么就老和我说：不好意思啊最近不怎么做技术了，忙啊，哈哈。所以个人取向不一样，我觉得也没什么，但别没事就贬人家。别的不说给你一个全新项目你自己搞你搞的定么。 </div>
<p>感觉确实有这么回事.不过固步自封与闭门造车是不可取的.</p>

17 楼 lz726 2008-08-06  

用软的方式,思考硬的世界,并抽象出来就叫软件的设计.

16 楼 black_zerg 2008-08-06  

我是说各人长项和兴趣不一样，这都正常。但比如一个人明明是开船的，有一天突然顿悟了，说造船不重要，不奇怪么？人家真正牛b的人研究方法学研究技术研究模式框架的忙了多少年了，你现在这么一下子就顿悟了，那人家算怎么回事。你要是直接说对饭碗的理解深了，大家就不会误会了。而且本来国内技术真的就很浮躁，有几个能坚持钻研一辈子的？本来中国人是绝顶聪明的，就是因为这种顿悟太多。技术上永远只能拾人牙慧。

15 楼 Joo 2008-08-06  

没看明白楼上的到底是贬管理层还是技术人员 还是both?

14 楼 black_zerg 2008-08-06  

吹吧，说实话我觉得管理人员确实很重要，但真正聪明人多数不乐意干，乏味。你以为你知道几张表是干嘛的就是懂软件设计了？软件设计应重于技术能力和分析能力，所以一个真正优秀的设计者可以立足於完全不同的情况，知道怎么去分析去给出方案，并有驾驭所需技术的能力。不是说你就知道点现成行业背景知道大概有什么流程就得了。我早年做过sap顾问之类，那些哥么更逗，一破表什么意思他都不会跟你说的，跟宝贝似的藏着。还有工作过的一个地方也逗，那破程序年久失修，啥文档没有，就几个遗留程序员知道大概怎么回事了，那个对知识的珍惜哟。 国内也就这个风气，干几年程序员再往下干，别人都看不起你，我一哥么就老和我说：不好意思啊最近不怎么做技术了，忙啊，哈哈。所以个人取向不一样，我觉得也没什么，但别没事就贬人家。别的不说给你一个全新项目你自己搞你搞的定么。

13 楼 风清云淡 2008-08-06  

项目经理如果只懂业务是绝对不行的。
领域建模要结合实现，否则高来高去，模型和实现割裂，最终模型一定会被破坏！失去他的作用。