Rails為例 軟件開發中需要更多的偏執
內容如下：
程序員有時候會讓你難以接受，因為他們對于自己使用的開發工具或開發方法有一種狂熱的偏執，給人一種很固執的感覺。而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的偉大之處在于，它決定了做如何的取舍，并一直堅持這條道路走下去。
它們這樣做就是向我們程序員宣告：這是我們的選擇。所以才出現了我們上面的討論，所以我們才要瞪大眼睛做出自己的選擇。
情況是：所有的平臺，框架，類庫都是偏執的。它們只是不去聲明，或者并不始終如一的偏執。它們不聲明，我們也就很難知道我們使用它們將會做怎樣的取舍。我們一開始就做出了錯誤的選擇，卻去抱怨工具的的不好。郁悶!
我堅持認為：不僅要有更多的偏執;而且我們要更好的表達出這些偏執是什么。
原文：http://www.aqee.net/2011/07/13/a-call-for-strong-opinions-in-software-development/
【編輯推薦】
