軟體開發中需要更多的偏執

　　程式設計師有時候會讓你難以接受，因為他們對於自己使用的開發工具或開發方法有一種狂熱的偏執，給人一種很固執的感覺。而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的偉大之處在於，它決定了做如何的取捨，並一直堅持這條道路走下去。

　　它們這樣做就是向我們程式設計師宣告：這是我們的選擇。所以才出現了我們上面的討論，所以我們才要瞪大眼睛做出自己的選擇。

　　情況是：所有的平臺，框架，類庫都是偏執的。它們只是不去宣告，或者並不始終如一的偏執。它們不宣告，我們也就很難知道我們使用它們將會做怎樣的取捨。我們一開始就做出了錯誤的選擇，卻去抱怨工具的的不好。鬱悶！

　　我堅持認為：不僅要有更多的偏執；而且我們要更好的表達出這些偏執是什麼。

英文原文連結：A Call for Strong Opinions in Software Development