Jul 12

控制发散思维 不指定

      深入开源世界的程序员的思维大多发散严重,这种发散在很多情况下是有害的。在制作一个新的产品/项目之前,很多人都会说,唔,你应该参考好的开源东西,把他直接使用。殊不知这样拿来就用伤害最大:因为自己根本没有机会仔细思考自己要做的东西是什么样子的。这就是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的联系,参考同类产品,进行重构或者集成。这么做的目标是控制住发散的思维,在有限的时间内拿出一个在当前状态下最好的方案与实现,没有底线的项目/产品是个毫无意义的泡泡,脆弱,除了作为夸夸的谈资,经不起明眼人的一锥子。
Tags: ,
发表评论
表情
emotemotemotemotemot
emotemotemotemotemot
emotemotemotemotemot
emotemotemotemotemot
emotemotemotemotemot
打开HTML
打开UBB
打开表情
隐藏
记住我
昵称   密码   游客无需密码
网址   电邮   [注册]