耐心无止境 成功一瞬间
BlogJava 联系 聚合 管理
  31 Posts :: 5 Stories :: 25 Comments :: 0 Trackbacks
值得思考的问题


在jdon上看了一个帖子，感受颇深，有一种“一语惊醒梦中人”的感觉。

我们为什么选择spring（或者其他框架），为什么出现了IOC,AOP,ORM等等？简单回答是“解决问题”，但他们解决不同的问题。

需要继续思考一下，希望能有所“突破”

参考url：http://www.jdon.com/jivejdon/thread/35373.html


防止断链，转载如下：

转载内容
一晃眼搞了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给你带来的福音。

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


posted on 2009-03-25 14:25 Joshua Yan 阅读(179) 评论(0)  编辑  收藏 所属分类: Java

只有注册用户登录后才能发表评论。
网站导航: