顿悟, 软件的设计

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

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

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

评论

12 楼 zenny 2008-08-06  

lurena 写道

举个例了

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

11 楼 mazzystar 2008-08-06  

<div class='quote_title'>hetylei 写道</div>
<div class='quote_div'>一个合格项目经理应该是此项目所涉及的行业专家 而不在乎于他的技术水平 所谓的企业应用，企业信息化建设最重要的还是提供合理的业务解决方案 而不仅仅是“信息化”</div>
<p><br/>确实需要一个行业专家来提供合理的业务需求，业务解决方案，但这个人不一定是项目经理</p>

10 楼 Joo 2008-08-06  

楼上的观点只能同意一半
一方面我赞同业务熟悉的项目经理能很好的理解需求，但是如果没有技术能力就不能从技术角度来看待和处理需求

9 楼 hetylei 2008-08-06  

一个合格项目经理应该是此项目所涉及的行业专家

而不在乎于他的技术水平

所谓的企业应用，企业信息化建设最重要的还是提供合理的业务解决方案

而不仅仅是“信息化”

8 楼 myiris_gm 2008-08-06  

同意楼上观点

7 楼 ladofwind 2008-08-04  

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

6 楼 lurena 2008-08-03  

gaoran2008 写道

其实你说下来还拘于你知道的技术层，模式只不过是干活的方式。系统设计－－－对需求和技术的熟悉，两者的兼容。

这是一个纯设计的讨论, 不涉及任何技术, 贴中所提到的技术词语也只是用来表达设计中各个部分的作用.
对于这个设计思想的提出, 这绝对不是我, 但现在我能理解其中的深意. 用哲学的观点来说, 可以这样理解:
没有采用这样的设计, 也能做好软件, 这样的软件一定采用了相应的设计方式/方法, 但所采用的设计越接近贴中提出的方法论, 这样的软件就越能适应需求.
举个例了, 你为某行业客户成功开发了一套软件, 但这套软件不一定能成功应用到此行业的其它客户,在不改动底层设计的前提下, 就能为客户提供服务和功能.如果是按贴中的设计原则, 则可以做到至少在行业内的产品软件具有一定的通用性.

5 楼 gaoran2008 2008-08-03  

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

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

声明:以人为本人现阶段的认识,有不足和错误之处,请拍砖.在此先谢过各位.
－－－－－－－－－－－－－－－－－－－－
其实你说下来还拘于你知道的技术层，模式只不过是干活的方式。系统设计－－－对需求和技术的熟悉，两者的兼容。

4 楼 Joo 2008-08-02  

这方面的问题如果o6z大师在就非常有意思了

3 楼 lurena 2008-08-02  

Joo 写道

感觉说这些未免有点虚，能不能就楼主的实际工作历程来讲讲你是如何从一个程序员转变成一个项目经理的?

所言不无道理, 但我所说的和你所说的不是一个层面上的事, 所以无法相提并论.
至于从程序员到项目经理, 这个话题很大, 简单说从两个方面, 一是个人取向, 二是机会.当然, 项目经理也只是概念, 不同的人有不同的理解, 我现在所做的项目经理, 是概念上的,没有太多的实现参考意义,不提也罢,只求能对项目有益.项目管理主要还是和人打交道, 和客户沟通,和同事沟通, 和上级沟通, 沟通的目的是规避风险,使项目正常进行.

引用

学习过哪些知识,从什么时候开始悟道,对那些有志称为PM或者构架师的朋友给一些建议?我总觉得无论是PM还是架构者,都不能离开技术基础于浮沙上谈管理谈构架,而是要结合具体的技术具体的人具体的成本具体的风险具体的项目性质来综合考量,而这些需要深厚的技术功底.

学习是一个过程, 悟道是过程的总结, 只有不断的学习,不断的总结,才有正果.从我的经历来看, 学习是为了解决实现工作中的问题而学习, 努力充实自己,让自己适应更多的情况.越是学习越是感觉自身的不足,现在也不敢说对JAVA精通,对设计模式精通,对流行框架精通,**精通.
学习的内容归为两个方面, 一是技术, 二是业务, 两者相辅相成.

引用

所以即便其中用到了模式,也是经过通过之前很多项目积累下来的经验进行选择的.自我感觉对Java我现在还刚入门, 更不要谈23种基本模式或者JavaEE核心模式多么了然于心,但是我是在工作中碰到什么才学习什么,反而针对性和驱动力更强,自己的成就感也因此更实在.我希望能一直这么样扎实的走下去,大家丢砖吧

同意你的观点, 大部分人都是这样过来的, 路总要扎实的走.

2 楼 Joo 2008-08-02  

感觉说这些未免有点虚，能不能就楼主的实际工作历程来讲讲你是如何从一个程序员转变成一个项目经理的?
学习过哪些知识,从什么时候开始悟道,对那些有志称为PM或者构架师的朋友给一些建议?我总觉得无论是PM还是架构者,都不能离开技术基础于浮沙上谈管理谈构架,而是要结合具体的技术具体的人具体的成本具体的风险具体的项目性质来综合考量,而这些需要深厚的技术功底.我就我自己的体会说说,其实在我们那年进公司的同事中,我是比较低调的一个,老大让我做PB我就做PB,让我用c#我就用c#,让我写存储过程我就研究存储过程,最后转Java大约也只是一年多之前的事情.而与此同时,很多其他的同时早就已经把TIJ+Design Pattern看了滚瓜烂熟了,张口闭口工厂单态范型云云.不过可能是公司项目性质的原因,可能是老大本身软件组整体考虑的原因,这些人的这些知识并没有起到多少作用,而真正有生产力的,还是我的c#代码,我的sql代码和别人都不屑或者不太上手的文档.
后来带两三个做项目了,首先也是先自省项目适合用什么样的技术,而不是用什么技术来做项目.手上的这几个人能力如何,对什么比较熟悉,工作态度如何是否能配合工作,个性怎样.然后尝试去多沟通多讨论,思考如何分配工作和计划时间.在做构架(谈不上真正的构架了,也就是技术选型)的时候,也是能用平一点的技术就用平一点的,不太敢去用最新时髦的咚咚,力争实用性和可靠性第一.所以即便其中用到了模式,也是经过通过之前很多项目积累下来的经验进行选择的.自我感觉对Java我现在还刚入门, 更不要谈23种基本模式或者JavaEE核心模式多么了然于心,但是我是在工作中碰到什么才学习什么,反而针对性和驱动力更强,自己的成就感也因此更实在.我希望能一直这么样扎实的走下去,大家丢砖吧

1 楼 jjx 2008-08-02  

革命尚未成功啊