“为什么Hibernate如此成功！”

“为什么Hibernate如此成功！”

http://hibernate.bluemars.net/38.html

这篇文章是Gavin King写的，非常有趣，充分体现了Hibernate的设计理念，我粗略的意译如下：

下面是对Hibernate开发工作的个人想法，正是这些工作使得Hibernate如此迅速的得到广泛的欢迎。

1、飞快的版本发布
保持活跃的开发速度，经常进行版本发布，甚至几天之内就从前一个版本开发到下一个版本。这样是保证软件远离Bug的最好的办法，也可以让用户感到很放心，确信Hibernate的开发十分活跃，另外这样做也有一大好处，就是可以发现哪些功能是用户真正需要的。

2、回归测试
我想现在整个Java社区一定都很重视自动回归测试。如果软件的功能和设计有比较大的修改，那么一个综合性的test suite对于软件可维护性和稳定性来说实在是太重要了。我们应该有这样的意识：如果对软件的一个新功能没有进行回归测试，我们根本就不该去做它。

3、把一个功能做到最好
要么不做，要做，就一定做到最好。那些我们做不到最好的功能，我们根本不去做，扔给其他软件去做吧。

4、避免过度设计
浪费大量的时间和精力进行软件功能的抽象和扩充软件的灵活性，还不如多花点时间来解决你的用户面临的实际问题呢！简单一点! 软件能跑起来就OK，不要尝试去解决你的用户根本不关心的问题。就算你的软件设计的不够优雅也没有关系，反正还是initial阶段嘛！以后再 refactor，你应该关注的问题是及时的把有用的功能给做出来。

5、集权
在你需要由民主投票来下决定之前，至少你已经把软件轮廓做好了。软件开发需要由一两个开明的人来领导，这样可以保证软件开发的连贯性而不至于产生太大的分歧，可以保证开发团队集中火力把要实现的功能做到最好。我觉得，OSS软件最大的风险就是意见不统一，摊子铺的太大，结果最后搞的什么都没有做好。

（译者按：非常赞同，凡是成功的OSS软件，都是在某个牛人已经把软件做好了之后，发布出来，然后由大家往里面添加功能的，并且在牛人的领导下不断进步。缺乏牛人的OSS软件都不算很成功，比如Mozilla）

6、文档
没有什么比文档更重要的了。如果你的用户不知道你的软件有这么一个功能，就等于没有这个功能，干脆把它去掉得了，省得给源代码增加复杂度。

7、避免标准化
好的标准可以带来软件的互用性和可移植性，坏的标准能够窒息软件创新！“支持XXX标准”根本就不是真实的用户需求，特别是当这个XXX标准是那些在其位不谋其政“所谓”的专家委员会制订出来的。（译者按：莫非指Sun，IBM等几个big name？）最好的软件是在不断的尝试，不断的出错，不断的经验积累的过程中产生的。 事实上的标准往往更加贴近用户需求。

8、10分钟之内把Hibernate跑起来
潜在的Hibernate的用户在他们下载了Hibernate，第一次使用的时候根本就不可能花半个小时那么多时间来安装、配置和 troubleshooting，他们早就丧失了对Hibernate的兴趣了。我们的口号就是新用户（假设有足够的JDBC知识）5分钟之内把 Hibernate的Demo跑起来，而他们能够在1个小时之内写出“Hello World”式的最简单的Hibernate程序并且正常运行。

9、开发人员的责任感
用户总是不可避免的碰到问题，开发团队有责任有义务提供帮助。用户让我们知道了文档的漏洞，用户让我们知道了测试用例的小bug。此外，没有用户来用我们的Hibernate，我们还开发它做什么，不是浪费时间吗！

有个关于bug的笑话：用户根本不介意发现新功能的bug（译者按：Windows的用户好像都是如此），只要你能迅速的改掉bug。“责任感”意味着 bug修复应该在1周之内。从收到bug报告到bug修复代码提交到CVS上要做到平均在24小时左右，这才是一个理想的目标。

10、易用的、可更新的wiki网页
（译者按：wiki是Hibernate网站用的一个web发布框架）

Hibernate入门容易，掌握精通我也不敢自夸。我第一遍看Hibernate文档的时候也觉得很吃力，但不是因为Hibernate难掌握而感到吃力，是因为Hibernate文档处处都是持久层设计的经验和最佳实践。Hibernate文档准确的来说，绝大部分内容都在讲对象的持久层设计，而不是简单的Hibernate使用，使用问题查Java doc就够了。所以学习Hibernate，主要是在学习持久层的设计模式，如果你把Hibernate文档都看完了，还整天只会提那些 Hibernate的配置问题，Hibernate的类调用问题，我觉得这样的人还没有真正的入门，算是白学了。

我对Hibernate 的那些配置也不是特别纯熟，每次写hbm，都要对照文档一点点的检查；类调用参数也不太记得，写代码也要Java doc随时备查。但是我在学习Hibernate的时候即集中所有精力来理解Hibernate的运行原理，集中精力来掌握持久层设计应该把握的原则和技巧，这些才对我是最重用的东西。毫不夸张的说，学习完Hibernate，我对JDBC的编程也提高了一大截，更不要说对于J2EE架构的持久层的框架设计，基本上是了然于胸了，即使将来换了API，不用Hibernate的，改用JDO，Castor什么的，这些经验一样照用。

学习Hibernate主要不是在学习Hibernat怎么配置，用工具怎么生成hbm文件，如果你把重点放在这里，基本上等于白学了Hibernate。Hibernate的精华在于无与伦比的灵巧的对象持久层设计，这些持久层设计经验不会因为你不用Hibernate而丧失掉，我自己学习Hibernate，已经明显感觉到对持久层设计能力已经长了很多经验值了，这些经验甚至不光可以用在Java上，用在.net上也是一样。所以Hibernate配置的学习，我只是简单看看，用的时候知道到那里去查就行了，一堆复杂的生成工具我根本就看都不去看，这样算下来，掌握Hibernate的配置，可以用Hibernate来替代JDBC写程序，不过花上3天时间就足够了。我想3天时间对你来说不算很奢侈的学习代价吧。

为什么我这么强调学习Hibernate的对象持久层设计理念呢？那就看你的理想是想一辈子做一个程序员呢？还是想向更高的方向发展呢？从纯做技术的角度来说，职业发展的最高点是“系统架构师”，Bill Gates不是还叫做微软的首席系统架构师吗？System Architect职位需要的是你的学习和领悟能力，如果你不能把学习Hibernate得到的设计经验运用到其它地方，那么你是失败的，也没有资格做 System Architect。

不管JDO也好，Hibernate也好，TopLink也好，CocoBase也好，还是 Castor，还是什么Torque，OJB，软件的使用和配置方法可以各异，但本质上都是ORM，都是对JDBC的对象持久层封装，所以万变不离其宗，如果你完整的学习和掌握Hibernate花了1个月的时间，那么你再学习OJB的时间不应该超过1个星期，因为你已经把对象持久层设计都了然于胸了，你需要的只是熟悉一下OJB的API和配置罢了，至于怎么运用OJB进行持久层的开发你早就已经熟悉了。

所以当你掌握了两种以上的ORM，你应该能够不拘于使用的ORM软件的限制，设计出适合于你的项目的持久层来，这才是System Architect的水准。用金庸小说来打个比方来说吧，张无忌学太极剑，只记剑意，不记剑招，这才是真正的高手，而低手就只会去学习剑招，而不去领会剑招背后蕴含的剑意，所以一辈子都是低手，永远不能真正学会太极剑。所以周颠看到张三丰第二次演示太极剑，招式完全不同就以为是另一套东西，其实本质上都一样。学习Hibernate也不要舍本逐末的去学各种五花八门的工具，重点掌握它的对象持久层设计理念。