控制发散思维
转自Michael Chen's Blog
深入开源世界的程序员的思维大多发散严重，这种发散在很多情况下是有害的。在制作一个新的产品/项目之前，很多人都会说，唔，你应该参考好的开源东西，把他直接使用。殊不知这样拿来就用伤害最大：因为自己根本没有机会仔细思考自己要做的东西是什么样子的。这就是Hibernate之所以创建EHCache的原因。在EHCache之前，已经有不少Cache实现，为什么没有直接使用？因为Hibernate自己都不知道Cache接口应该是什么样的。因此有了小小的简陋的EHCache, 正是有了这个小小的东西，其他Cache机制的集成才成为可能。因为Hibernate知道与外界集成要遵循的接口是什么。如果当初直接采用某一种Cache实现，恐怕就没有了现在灵活的Cache机制了。
（这种思维的方式同样可以推广，为什么小公司不愿意接受数额较大的融资，因为这样很容易将小公司原本不太清晰的发展观念冲垮，最后什么也不是。）
现在设计平台，发现陷入了这样一个怪圈：我总想将最新最好的开源产品集成到平台中，却忽略了Roadmap Feature的定义，也就是说，没有一个清晰的标尺来定义平台某一个版本应该包含那些特征，应该达到什么效果。这样做的后果是我陷入在一个又一个优秀的产品中，像上瘾的烟鬼拔不出来。在深邃的开源世界里，一切的一切都太又诱惑了：为了选定一种O/R映射方案，我比较了JDO的各种实现以及Hibernate，阅读了大量文档（广告？），最后还是回归到Hibernate; 为了选定一种Mock测试方案，我比较了EasyMock, jMock, 之前我从未用过Mock测试，现在我对EasyMock的机制已经相当清楚了；为了选定一种代码覆盖率工具，我比较了Clover, Jcoverage和Emma，最后选定了Jcoverage， 为了选择一种IoC容器，我比较了Spring和 HiveMind，最后选定Spring, 为了选定一种Web开发框架，我重新审视并比较了SpringMVC, WebWork, Struts, Tapestry.，最后选定了Tapestry。这个过程充满了感叹，也充满了诱惑性：很多具有相关性设计精美的项目会时不时招摇的在你眼前晃来晃去，让你忍不住看下去，然后你一个下午的光阴就耗费在从Google或者TSS或者JavaLobby一个链接开始而引入的一个深渊，留下你无法弥补的4个小时的时间。看着越来越近的Release Date, 心情越来越不爽。
因此，一旦前期调研结束，程序员应当果断的将与开源的联系一举切断，专心致志的投入到实现中去，一旦发现有可能抠出新的设计的地方，不要马上就找开源的产品，请先用自己的智慧设计一个能用哪怕是破败不堪的（好的设计是重构出来的，不是吗？）东西，先将框架搭建出来，一个迭代过后，开始重构，等到这个设计基本成型了，能够运行了，然后重新获得与OS的联系，参考同类产品，进行重构或者集成。这么做的目标是控制住发散的思维，在有限的时间内拿出一个在当前状态下最好的方案与实现，没有底线的项目/产品是个毫无意义的泡泡，脆弱，除了作为夸夸的谈资，经不起明眼人的一锥子。