程序员有时候会让你难以接受，因为他们对于自己使用的开发工具或开发方法有一种狂热的偏执，给人一种很固执的感觉。而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的伟大之处在于，它决定了做如何的取舍，并一直坚持这条道路走下去。

它们这样做就是向我们程序员宣告：这是我们的选择。所以才出现了我们上面的讨论，所以我们才要瞪大眼睛做出自己的选择。

情况是：所有的平台，框架，类库都是偏执的。它们只是不去声明，或者并不始终如一的偏执。它们不声明，我们也就很难知道我们使用它们将会做怎样的取舍。我们一开始就做出了错误的选择，却去抱怨工具的的不好。郁闷！

我坚持认为：不仅要有更多的偏执；而且我们要更好的表达出这些偏执是什么。

分享这篇文章：