有了OO、分层、DI、AOP、TDD和Refector,DDD不再是空谈

08-12-31 lgx522
一晃眼搞了7、8年的企业应用管理和研究,各种技术、思想翻来覆去折腾了很久,最近总算是有点持拨云见目的感觉了,于是放出点大标题和各位论论道。

主要观点其实在一年半前,已经在jdon首发的文章“坚持发扬EJB、Spring的光辉思想,将组件化进行到底!”(可参 http://www.jdon.com/jivejdon/thread/31834.html)进行过论述。当时虽然观点比较激烈,然实际上笔者领悟得不够深刻,故有后面一年多的RoR和PHP之实践。随着时间的推移,与各相关方(上级领导、企业领导、用户、开发商主管、设计人员、开发人员、维护人员等等)的更多观点接触,让我逐渐深入领悟了Java和Spring所蕴含的开发哲学和思想,于是又有此文。

(上文刚刚收到blog,由于是老文,不再发布了,仅作为整理收录)

如果说,每种编程语言和技术都有自己的目标和归宿和话,那么简单来说,JavaEE和后来的Spring是为企业应用而生的。他们诞生的基本目标,正是为了解决困扰企业应用多年的各种复杂问题。故而他们能够达到现在的领导地位,并将一直延续下去。

世间各种事业,都应该是“统一规划,分步实施”。放到信息工程来说,就是“自顶向下设计,自底向上实现”。道理谁都明白,可现实当中执行下来,总是要走样。问题就在于,这二者该如何结合?于是实际项目中,企业用户、分析师、设计师、程序员、维护人员总是不欢而散,最后往往各行其事,一盘散乱。上层的总是抱怨下层在“乱搞”,而下层则嘲笑上层只会“空谈”。结果往往是早已扔进档案袋的系统方案和图表,一堆各种公司、各种程序的“系统”,蒙头蒙脑瞎忙的维护人员。

那为什么结合不了?因为大家没有“共同语言”。开初UML跳出来了,分析师讲得头头是道,程序员看得心烦意乱,用户更是云山雾水。于是连MF都有点烦了,干脆推起了RoR。这乍东西一看太理想了。几乎是分析员可以直接实现程序,而程序员也可以直接分析了。可惜世间难有完美的事物,RoR这种过于“ 霸道”的东西也许还是有问题的。前有foxpro,后有VB、PB,也许是笔者总是心有余悸,对这种过于“完美”的东西还是先放一放吧。

那是不是说,大家真的不可能有“共同语言”?笔者以为,有,但要折衷(又闻到了实用中庸主义的味道了吧)。如题,OO、DI、AOP、TDD和Refector正是当前的解决之道。

OO是根本,可以作为基本的“共同语言”。图表不必要像UML那么复杂,否则最后除了分析师谁都不会看。只需要简单建上模型,标上属性和接口功能,最多连几根线说明相互关系,这样大家都懂(也就是说,这个类是个什么东西,有什么属性,要实现些什么功能)。这种东西既可做系统说明书,也可以给开发人员,甚至生成Doc做维护文档。

大家要说这不是“空谈”吗?要的就是空谈(就好比不识字的老百姓也会谈治国问题),就是只谈“有什么”和“做什么”,这样才能有共识。但这种“空谈”其实最难最费时,因为要“共识”。有了共识之后就可以下一步了。

下一步是实现。这个阶段,分层、DI、AOP就可以大展本领了。Spring流行那会,大家是言必DI和AOP。可惜风头一过,现在RoR和 Seam时尚年代,很多人大概忘了七七八八。其实笔者现在看来,分层、DI和AOP是继OO之后最重要的思想,它们的核心在于“接口和实现分离”。这样一来,就可以把“做什么”和“怎么做”分家,这才是它们的伟大之处。大家天天把“高内聚、低耦合”挂在嘴边,各搞一套,乱七八糟。J2EE太复杂,大家觉得用不上。好不容易Rod推行了用得上的标准方法,大家本可以有“共同语言”了。可惜人之天生的惰性又把我们推回到“一体化”的泥潭,一代代程序员和系统就这么不了了之了。

OO还是要坚持,它是当前信息世界和现实世界实现映射的最好方法。DI和AOP也是要坚持,只有这样才能屏蔽掉具体实现技术疯狂变化的信息世界。坚持OO,我们才能不受数据存储方式变化的困扰;坚持分层、ID、AOP,我们才能明确地分工合作,摆脱系统规模和事务要求变化所带来的烦恼。

最后还有TDD和Refactor,业务在变,系统在变,我们的技术也在变。一定要能测试和重构,要能很好地测试和重构,否则系统必被变化所毁。要想能够很好地测试和重构,如果你的系统没有OO、分层、DI、AOP,大家是否真可以充满底气地回答“能”。在这一个问题上,Java是最令我放心的伙伴,而Spring更总是带来惊喜。

DDD(领域驱动设计)是一个好的设想,而如今像Spring这类的标准化框架则可以把这个设想变为现实。在这个设想里,管理人员、分析师和用户定义模型功能要求,架构师根据要求选择技术方案,不同的程序员(有做dao的、做service的、做view的)根据接口要求实现代码,通过测试后提交。而因为有支持分层、DI、AOP的框架存在(比如说Spring),布署人员就可以简单地把他们组装在一起。

面对不断的需求变化,分析师仍然只需增加/变动模型和功能接口,测试人员和编程人员按作相应变化即可。

总体设计、分步实施、按需定制、分工合作、无缝组装,这种工业标准化的软件开发方式才是企业应用的答案。而OO、分层、ID、AOP、TDD和Refactor是真正支撑这个开发方式的支柱。以这样的方式,DDD会真正成为现实。

信息发达国家的软件业其实很大程度上已经实践了这种开发方式(想想那些大规模的外包吧)。这些年国内搞Java的,张嘴闭口便是SSH。可惜很多人搞了一些年后,还是“不识庐山真面目”,成天抱怨“好烦”。在这样浮燥的产业环境下,国内大多数企业应用的质量是低劣的。

即使你天天在写Java、天天在用Spring,如果不能够“知其所以然”,那么你的SSH注定是偷工减料的豆腐渣。所以在此劝诸位从事企业应用的同道,好好静下心来,认真思考一下你的应用所面对的各种问题,再好好思考一下OO、DI、AOP、TDD和Refator给你带来的福音。

愿大家的系统质量都能更上一层楼,这样才可变恶性竞争为良性合作,让我国的信息系统发挥更大更好的作用。

1
coolboyyang
2008-12-31 13:32
LZ说的很好。很有深度,国内许多企业只注重眼前利益,不愿意过分的产品拖的研发时间太长。哎,而且还定死技术选择。

shinesuo
2008-12-31 13:39
我只能说,顶.有思考力的人,如果都这样想就好了.

xmuzyu
2009-01-01 00:36
>>DDD(领域驱动设计)是一个好的设想,而如今像Spring这类的标准化框架则可以把这个设想变为现实。

这句话,晚辈不是很理解,还请前辈们点拨,我觉得spring对DDD的作用也不是很大(但是不能否认spring给企业级开发带来的革命性的新思想),我们现在最多也就是将系统的service和一些repository类交给spring ioc容器装配,让IOC 容器来帮我们管理它们的生命周期,并且让spring管理事务等,但是对于我们的业务核心,实体,值对象等都需要自己管理,比如通过聚合,工厂,仓库来管理,而spring是不能管理的,所以有点不解,请各位道友指点迷津。

dearshor
2009-01-01 17:10
基本认同前辈的观点,但有一些观点,我不大认同,下面我对此谈一下我的几点思考。

On 2008年12月31日 11:30, “lgx522” wrote:

>下一步是实现。这个阶段,分层、DI、AOP就可以大展本领了。Spring流行那会,大家是言必DI和AOP。可惜风头一过,现在RoR和 Seam时尚年代,很多人大概忘了七七八八。其实笔者现在看来,分层、DI和AOP是继OO之后最重要的思想,它们的核心在于“接口和实现分离”。这样一来,就可以把“做什么”和“怎么做”分家,这才是它们的伟大之处。大家天天把“高内聚、低耦合 ”挂在嘴边,各搞一套,乱七八糟。J2EE太复杂,大家觉得用不上。好不容易Rod推行了用得上的标准方法,大家本可以有“共同语言”了。可惜人之天生的惰性又把我们推回到“一体化”的泥潭,一代代程序员和系统就这么不了了之了。

>...

>即使你天天在写Java、天天在用Spring,如果不能够“知其所以然”,那么你的SSH注定是偷工减料的豆腐渣。

您说“又把我们推回到‘一体化’的泥潭”,是反对现在的RoR、seam等full stack framework吗?那您是鼓励大家花大把大把的气力去自己整合S.S.H.,以及其他可能需用到的各种各样的技术吗?有能力把这个事做好,固然再好不过,问题是什么人都能做的好吗?即便做好了,重用性能有多少?要做好这件事需要深厚功力的,如banq能做出一个jdon framework出来,提升到了框架的高度;您“搞了7、8年的企业应用管理和研究”,或许也能做出一套自己的最佳实践出来。但是如果没有您们这样的功力,即便他“知S.S.H.之所以然”,也无法把这三者整合好,也无法进而做好自己的project,只能是偷工减料的豆腐渣。

掌握了基础设施原理,学会优秀的设计思想、设计模式、设计方法,到最终把这一切付诸实践,获得最佳实现/实践,这“想”与“做”之间的距离,绝对要比你想象的要大的多,不是什么人都能轻易跨得过去的。

暂时跨不过去怎么吧?这时不能什么都不干啊,该干嘛还得干嘛啊,这时候就可以去用“full stack framework”。一个优秀的full stack framework,其关键意义之一就在于“无缝整合”四字,整合各种各样你需要用到的优秀技术,给你一个优质的基础设施、基础平台(避免自己整合搞出偷工减料的豆腐渣工程来),让你直接可以在此之上构建上层建筑。但又不会把你绑定在某个或某几个特定的技术上,用什么、不用什么,完全由你自己选择,同时又不用担心整合的问题,有能力的话,还可以方便的加入自己的扩展。所以,full stack framework绝不是“泥潭”!也不是让你丢弃“OO、分层、DI、AOP、TDD和Refector,DDD”,而只是帮你做了一些核心工作,让你不用那么辛苦,不用什么都要去从零开始或从一个很低的起点开始做起。

继承别人的成果不可耻,直接使用别人的成果也不可耻,在别人已经达到的高度上继续努力,才能走的更高、更远,发展才能更迅速。重复别人已经做出成果的事情,那才是无意义的很。那些什么东西都希望自己从原理出发,自己设计、自己实现出来的人,是出于一种什么心理、心态?你想向世人证明你多么聪明,能发明出这么好的东西来?

不要只继承前人的总结出的思想、原理(OO、分层、DI、AOP、TDD和Refector,DDD),前人优秀的具体实现成果也要继承。 等到了你真正能够跨过“想”与“做”之间的距离时,你可以做出自己的基础设施,再用自己的基础设施搭建出自己的 full stack framework来,把这个留给后来人,作为后人继续发展的平台,如此传承、进步不息... 这才真正叫做“自己的贡献”。

[该贴被dearshor于2009-01-01 17:12修改过]

猜你喜欢
4Go 1 2 3 4 下一页