Read Sean

Read me, read Sean.
posts - 508, comments - 655, trackbacks - 9, articles - 4

接着上一篇的思路聊。既然我们可以把开发者社群看作一个整体,copy-paste别人的blog文章就是在违背DRY的精神,其实所谓"重造轮子"道理也是一样,既然别人都已经做了相同的事情,并且把它开源了,并且你看了它的代码以后,觉得做得不错,为什么还要自己费心去实现同样的功能呢?自己来实现能给你带来什么好处呢?

我可以列举一些我认为可能会让我们选择自己来做的理由:

  1. 我比其他人更了解我们自己的需求。
  2. 自己实现起来更容易,代码量更小,也更好用。
  3. 我是做技术的,能够DIY,就DIY,这样更能体现我的价值。

这些理由有它的道理,但是我们有必要仔细掂量掂量:

  1. 我比其他人更了解我们自己的需求。这是软件开发中很常见的一个误区,客户的需求难以把握,随着时间的推移,我们自己的技术层面的需求实际上也在不断变化,开源的框架往往经历了更多的考虑和验证,并且有一群热心的维护者帮你做bug-fix和升级,甚至我们自己就可以成为这群热心人中的一员。
  2. 自己实现起来更容易,代码量更小,也更好用。一开始确实是这样的,开源的框架为了满足不同的需要,往往需要比我们自己写代码要更加复杂和冗余,但是自制框架意味着我们自己定义的接口规范,这个接口规范能不能够在整个项目周期保持稳定暂且不谈,就算接口实现的再简单,项目中其他人也需要时间去理解和消化,然后记住一个定义好的调用方式,今后新加入的工程师也需要学习这个接口规范。开源框架则做得更好,一方面在这个项目中积累和学习到的知识,可以直接用在其他采用同一框架的项目中,另一方面新加入的人如果有过该开源框架的开发经验,上手时间可以缩短。
  3. 我是做技术的,能够DIY,就DIY,这样更能体现我的价值。我必须承认,我本人就亲身经历过这样的情况。在即将结束的这个项目中,我甚至自己DIY了一个简易的.NET报表引擎,为的是甩开Crystal Reports。一开始能够DIY报表引擎的想法让我兴奋得睡不着觉,最终前后花了3天很满意的完成了设计和开发,并交付报表开发人员重画报表。可是真正用了一段时间之后,基本的需求满足了,基本的可扩展性也具备,但是缺少可视化设计器、更灵活的公式、更丰富的报表元素,基本上就定型了,没有人有时间和精力再去维护它。

在很多开发团队,大家经常碰在一起讨论具体的技术和设计,这很有必要,有时也不可避免。但是也许Joel Spolsky说的对,软件设计很难,但是比设计软件更难的,是同整个team一起设计软件。做技术的,对于自己了解、掌握、做过、尝试过的东西,对于自己熟悉和信任的东西,多多少少有些偏袒,而对于新的、自己不了解、不熟悉的东西,则难免心存疑虑。这就难怪很多设计讨论会最终很难达成一致。这个时候,要么由技术上的最高权威直接拍板,定下来是什么就是什么,要么就分歧双方或多方各自陈述,然后由项目外部的实体进行独立仲裁。

我看好开源框架,尤其是那些经过考验广泛被采用的框架,因为相比自制框架,它们有着更大的优势。



只有注册用户登录后才能发表评论。


网站导航: