Rails為例 軟件開發(fā)中需要更多的偏執(zhí)
內(nèi)容如下：
程序員有時候會讓你難以接受，因為他們對于自己使用的開發(fā)工具或開發(fā)方法有一種狂熱的偏執(zhí)，給人一種很固執(zhí)的感覺。而Smart Bear Software軟件公司創(chuàng)始人Jason Cohen卻指出了一個相反的觀點：軟件開發(fā)中的偏執(zhí)是件好事。
你會突然發(fā)現(xiàn)，所有的軟件框架都很偏執(zhí)。我喜歡它們這樣。我們需要它們偏執(zhí)。
敏捷開發(fā)宣言是頭一個清晰的表達(dá)出它的偏執(zhí)觀點的好樣板。沒有模棱兩可的話，有的只是明確的取舍，例如評估對比“可運行的軟件”和“全面詳細(xì)的文檔”。如果你要問是該去寫一個需求文檔，還是寫一個具有可讀性的集成測試用例，你很清楚的能知道一個敏捷份子會怎樣回答。
Ruby on Rails的偏執(zhí)更強(qiáng)烈，例如這無處不在的“約定優(yōu)于配置”思想。不管你何時用它，你完全可以相信，Rails里寫出一個方法會讓你節(jié)約更多的字符。
大多數(shù)的軟件開發(fā)方法都是在宣揚一種哲學(xué)或思維定式。在很多團(tuán)體里這的表現(xiàn)的很明顯，他們對某種編程語言深信不疑。有些軟件創(chuàng)業(yè)團(tuán)隊或公司對一些“大家熟知”的企業(yè)文化奉若圣經(jīng)。你也許并不會贊成他們的一些基本觀點，但一個得到共識的信念會讓一個團(tuán)隊更加緊密。
事實上，Rails的偏執(zhí)如此的走極端，以至于讓人懷疑它的一些做法是否值得。例如，在RailsGuides——一個討論Rails基本知識的地方——當(dāng)他們談?wù)揜ails代碼生成引擎時，他們特別的指出，使用一個空的controller類就能讓你把頁面跑起來，這是多么的酷。但他們隨即就接著說，在實際使用中，你總是需要一個這樣沒什么用處的controller類來幫你讓東西跑起來。
為什么非要搞一個這樣的空類?這不很讓人困惑嗎?你幾乎從來不用它。
對于這個問題，我可以寫出一大篇文章，但這不是重點。重點是，從大方面來看，這樣的策略有很明顯的好處：
更少的代碼
… 這意味著更少的bug
… 這意味代碼更容易維護(hù)
一旦一個程序員知道了這種約定，他將會有更高的效率，因為在新開發(fā)或維護(hù)舊的軟件時，他都不需要寫那些公式化的代碼了。
一個程序員對一個陌生的項目能很容易的上手，因為這些約定在所有Rails項目中都是相同的。很多東西你都不需要去思考或爭論。
就像編碼風(fēng)格，如何編寫已不重要。重要的是大家都有共識，Rails的約定是統(tǒng)一的。
但這也有很明顯的弊端：
對于一個Rails新手來說，你數(shù)小時也未必能寫出幾行能用的代碼，因為從代碼上你看不出什么用處。
當(dāng)Rails改變約定時(例如遷移到Rails 3)，很多的東西都不能用了。而且，約定改變導(dǎo)致的問題你很難找出原因，因為代碼本身看不出什么錯誤。例如，當(dāng)Java里的接口改變時，你的程序是編譯不過去的。Ruby 和 Rails 可不是這樣。
如果你沒有很好的代碼測試覆蓋率的話，那很容易出問題，因為你的開發(fā)工具連最基本的錯誤都不會提示你。這導(dǎo)致了很多愚蠢的bug，你浪費了大量的時間去編寫和維護(hù)一些只是用來檢測***bug的測試用例。
你很難寫出，或根本不可能寫出一些有用的開發(fā)工具——例如代碼自動反射——因為這些代碼里沒有包含足夠的信息。這意味著你要手工寫更多的代碼，工具不能幫你。
Rails這樣做“對”嗎?也許一個禪宗大師會這樣說：你這是個錯誤的問題。
問題應(yīng)該是：對于你的項目，你的團(tuán)隊，你的文化，你的目標(biāo)，你應(yīng)該做如何的權(quán)衡取舍?
而Rails的偉大之處在于，它決定了做如何的取舍，并一直堅持這條道路走下去。
它們這樣做就是向我們程序員宣告：這是我們的選擇。所以才出現(xiàn)了我們上面的討論，所以我們才要瞪大眼睛做出自己的選擇。
情況是：所有的平臺，框架，類庫都是偏執(zhí)的。它們只是不去聲明，或者并不始終如一的偏執(zhí)。它們不聲明，我們也就很難知道我們使用它們將會做怎樣的取舍。我們一開始就做出了錯誤的選擇，卻去抱怨工具的的不好。郁悶!
我堅持認(rèn)為：不僅要有更多的偏執(zhí);而且我們要更好的表達(dá)出這些偏執(zhí)是什么。
原文：http://www.aqee.net/2011/07/13/a-call-for-strong-opinions-in-software-development/
【編輯推薦】
