开源框架VS土制框架

真的没想到，现在还会出现是否应该使用开源框架的争论。说说我很久以来的看法，权作一笑：

[quote]版权问题[/quote]
很多Java开源项目都使用ApacheLicence2.0或者LGPL，商业软件中使用完全没有问题。

[quote]开发人员积极性问题[/quote]
普通的开发人员，都更愿意学习流行的框架，也就是说积极性更高。说实话，对员工的发展也更好（找工作更容易）。有的时候，就会有人抱怨为什么不用Spring啊这些，然后有的人要么会偷偷使用，要么会搞一个稀奇古怪的自己的东西，很影响项目开发，维护。

[quote]维护问题[/quote]
维护自制的框架需要工作量，由谁去维护成为一个问题。修改过程中，避免BUG出现，保证不影响以前的客户端代码也是一个问题。

[quote]可移植性问题[/quote]
自制的东西很少遵守标准开发，如果再加上满地的静态方法和丑陋的设计，想要进行单元测试都是空话，想修改后不出BUG是不可能的，当然，想要移植就更加困难。尤其是满地的DBConnectionManager、ConnectionPool、DBUtils，再加上遇到同名不同包的情况（几个相同名字的连接管理类，存放在不同的包，但连接不同的数据库），想不改出问题很难。一个标准的javax.sql.DataSource接口就那么难实现？
说到移植性，又顺便说下普通的IOC原则，看看下面这个简单的代码就知道了：
[code]
public class UserDao{
public void createUser(User user){
Connection conn = DBConnectionManager.getConnection();
}
}
[/code]
移植的时候，除了DAO，是不是还需要把DBConnectionManager这个东西给带过去？再看看下面这样的：
[code]
public class UserDao{
private DataSource dataSource;
public void setDataSource(DataSource dataSource){
this.dataSource = dataSource;
}

public void createUser(User user){
Connection conn = this.dataSource.getConnection();
}
}
[/code]
现在UserDao的实现只依赖DataSource这个接口，移植的时候，直接修改DataSource配置，传入不同DataSource就是了。单元测试就更加简单，手动setDataSource就行。
而前面那个代码怎么单元测试？DBConnectionManager容易替换吗？是不是还需要修改DBConnectionManager的源代码？那要是在jar包里面呢，又怎么修改？移植就更麻烦了，要是移植到的系统已经有个相同名字的DBConnectionManager，但需要取连接的却是另外一个叫做DBUtils的类（一个项目中连接多个数据库很常见吧？），又怎么办？很多时候，用静态方法都不得不手动修改代码，就祈祷全文替换不要出错误吧。
第二种实现看似代码长度增加了，多了个setDataSource方法，可想想，如果还有其他的editUser,deleteUser，代码长度谁更有优势，是不是还需要每次都去调用这个恶心的长长的DBConnectionManager？
这个是DAO，当然不需要单元测试，其他service代码里的什么静态工厂引用就会遇到单元测试问题了。


[quote]性能和稳定性问题[/quote]
开源框架的开发人员基本都是高手，一般是每个公司最好的程序员。像Rod Johnson、Gavin King等人，比起一般公司里的开发人员，根本不在一个档次，甚至根本没必要拿来比。当然，SourceForge上粗制劣造的开源项目也不少，但这种东西注定了不会流行，流行的都是开源项目中的佼佼者。甚至可以说，开源项目强烈影响和冲击了各种标准，Spring和Hibernate，彻底颠覆了旧的EJB2，然后才有了更加先进的EJB3(JSR-220)，而其中的JPA（Java Persistence API），更是Hibernate的一个子集。实在不能把开源框架的性能和稳定性作为质疑的条件，难道自己制造的框架就一定比开源的更稳定？难道自制的框架都有很完备的测试？在质疑的同时，是否对这些开源项目有过较深入的了解，或者说是否使用过？是否真正知道使用后的好处与坏处？如果根本不了解，又如何能质疑它们？
自己不去了解就永远也不知道是否有性能问题，也许根本不存在呢？稳定性？说实话，我更怀疑根本没有经过单元测试就制造出来了的代码。

[quote]嗯，看上去不错，用熟练了可能也很好，但这些框架都需要一个熟悉的过程，需要代价。[/quote]
这是一个伪命题，为什么呢。说这些话的人都是搞了一套自己的框架，对于他们来说，使用其他框架当然需要学习。但对于公司其他人来说，使用这些自制的框架也需要学习，遇到稀奇古怪的问题也很郁闷，如果开发这个框架的人不在公司，只能自己从代码中慢慢找错误。这个是有切身体会的，很郁闷，不客气地说，很多自制的代码基本上比开源的差了不止一个档次，不容易跟踪到错误根源。

[quote]那好，从别的框架取出好的部分，消化后转换为自己的代码。[/quote]
FT。首先需要自己维护，麻烦。文档要重新写，麻烦。转换过程中不一定像开源框架那样有完整的测试（单元测试，集成测试），容易出错。最重要的问题，看似自己消化掉了，转换为了自己所理解的。但是没有参与“消化”的程序员，面对被“消化”掉重新构造出来的代码，难道就不需要消化了吗？像StringUtils这种东西，jakarta-commons-lang有一大堆方法了，再自己去写相同功能的就实在没有必要。自己写的web框架，就更容易漏洞百出了，自己写的就是比WebWork好？我相信，每个人都比Richard Oberg、Lightbody等人牛。

[quote]那么，我们为什么要用开源框架[/quote]
为了赶时髦。:)
为了和外面的世界接轨，为了用标准开发，增加可移植性。
为了框架挈约杜绝不好的开发方式，使项目更容易维护。
为了各个项目组之间不再各自行事，都重复搞一套自己的轮子。
为了让员工积极性更高。
当然，最重要的是为了解决实际问题，更好更快速地完成任务，达成目标。像那个臭名昭著的数据库连接泄露问题，很简单地用一个拦截器就搞定了，还需要千方百计、想方设法吗？借鉴他人成果，减少自己无谓的工作量，提高项目开发效率，降低维护成本，这才最根本的。