程序员有时候会让你难以接受,因为他们对于自己使用的开发工具或开发方法有一种狂热的偏执,给人一种很固执的感觉。而Smart Bear Software软件公司创始人Jason Cohen却指出了一个相反的观点:软件开发中的偏执是件好事。
你会突然发现,所有的软件框架都很偏执。我喜欢它们这样。我们需要它们偏执。
敏捷开发宣言是头一个清晰的表达出它的偏执观点的好样板。没有模棱两可的话,有的只是明确的取舍,例如评估对比“可运行的软件”和“全面详细的文档”。如果你要问是该去写一个需求文档,还是写一个具有可读性的集成测试用例,你很清楚的能知道一个敏捷份子会怎样回答。
Ruby on Rails的偏执更强烈,例如这无处不在的“约定优于配置”思想。不管你何时用它,你完全可以相信,Rails里写出一个方法会让你节约更多的字符。
大多数的软件开发方法都是在宣扬一种哲学或思维定式。在很多团体里这的表现的很明显,他们对某种编程语言深信不疑。有些软件创业团队或公司对一些“大家熟知”的企业文化奉若圣经。你也许并不会赞成他们的一些基本观点,但一个得到共识的信念会让一个团队更加紧密。
事实上,Rails的偏执如此的走极端,以至于让人怀疑它的一些做法是否值得。例如,在RailsGuides——一个讨论Rails基本知识的地方——当他们谈论Rails代码生成引擎时,他们特别的指出,使用一个空的controller类就能让你把页面跑起来,这是多么的酷。但他们随即就接着说,在实际使用中,你总是需要一个这样没什么用处的controller类来帮你让东西跑起来。
为什么非要搞一个这样的空类?这不很让人困惑吗?你几乎从来不用它。
对于这个问题,我可以写出一大篇文章,但这不是重点。重点是,从大方面来看,这样的策略有很明显的好处:
- 更少的代码
- … 这意味着更少的bug
- … 这意味代码更容易维护
- 一旦一个程序员知道了这种约定,他将会有更高的效率,因为在新开发或维护旧的软件时,他都不需要写那些公式化的代码了。
- 一个程序员对一个陌生的项目能很容易的上手,因为这些约定在所有Rails项目中都是相同的。很多东西你都不需要去思考或争论。
- 就像编码风格,如何编写已不重要。重要的是大家都有共识,Rails的约定是统一的。
但这也有很明显的弊端:
- 对于一个Rails新手来说,你数小时也未必能写出几行能用的代码,因为从代码上你看不出什么用处。
- 当Rails改变约定时(例如迁移到Rails 3),很多的东西都不能用了。而且,约定改变导致的问题你很难找出原因,因为代码本身看不出什么错误。例如,当Java里的接口改变时,你的程序是编译不过去的。Ruby 和 Rails 可不是这样。
- 如果你没有很好的代码测试覆盖率的话,那很容易出问题,因为你的开发工具连最基本的错误都不会提示你。这导致了很多愚蠢的bug,你浪费了大量的时间去编写和维护一些只是用来检测弱智bug的测试用例。
- 你很难写出,或根本不可能写出一些有用的开发工具——例如代码自动反射——因为这些代码里没有包含足够的信息。这意味着你要手工写更多的代码,工具不能帮你。
Rails这样做“对”吗?也许一个禅宗大师会这样说:你这是个错误的问题。
问题应该是:对于你的项目,你的团队,你的文化,你的目标,你应该做如何的权衡取舍?
而Rails的伟大之处在于,它决定了做如何的取舍,并一直坚持这条道路走下去。
它们这样做就是向我们程序员宣告:这是我们的选择。所以才出现了我们上面的讨论,所以我们才要瞪大眼睛做出自己的选择。
情况是:所有的平台,框架,类库都是偏执的。它们只是不去声明,或者并不始终如一的偏执。它们不声明,我们也就很难知道我们使用它们将会做怎样的取舍。我们一开始就做出了错误的选择,却去抱怨工具的的不好。郁闷!
我坚持认为:不仅要有更多的偏执;而且我们要更好的表达出这些偏执是什么。
不是偏执,而是学好一门语言不容易
学物理的对物理是不是有偏执呢,我想也是吧
学物理的不可能对化学会偏执