轉 軟體開發中沒有所謂正確的方法

驅動測試開發(TDD)是唯一能讓你寫出沒有bug的程式的方法。只有結對程式設計是可行的。我們之所以成功就是因為我們使用的是遠程開發人員。等等等等……

像這樣的話每天我都能看見。

像這樣的風言風語十分能蠱惑人心，它愚弄我們，讓我們認為這就是我們不能遇到阿拉丁的那個茶壺裡的精靈的唯一原因。最終，這些人所寫的會讓你也這麼認為。

如果你隨機找100個程式員，問他們“開始一個新項目前首先想到的技術方案上什嗎？”相信你會得到100種不同的回答。

那麼，為什麼有這麼多的人看起來堅信自己的方法才是唯一可行的？

在我看來，這答案既十分的簡單，又十分的複雜。說簡單，是因為有些人就是喜歡說。說複雜，是因為軟體業實際上是一系列亞文化的彙總，它們不斷相互對抗來保衛自己的職業安全。我知道，這話有多重含義。

我之所以會談論這些，全是因為昨晚讀到了Chris Sturgill的一篇文章，是關於測試以及它們如何被過度吹捧。文章提到的所有觀點都有理有據，令人信服。

但這篇文章後面跟隨的評論描述的卻是一副完全不一樣的景象。如果你不看文章唯讀評論，你會以為Chris腦子進水了或出來什麼其它事。他怎麼敢質疑TDD?他怎麼膽敢質疑測試驅動文化的有效性？

看了這些評論後，我感覺有一股力量在逼迫我去寫點什麼。但我的這篇文章絕對不是來討論什麼TDD的。我想討論的是如果成為一名優秀的軟體開發人員。

讓我們進入正題。

軟體開發中沒有所謂“正確”的方法。我重申：軟體開發中沒有所謂“正確”的方法。編程界裡有些人喜歡搞圖騰崇拜，他們拒絕接受這樣的事實。他們執著於幾小時前剛學到的一些誘人的新出現的熱門技術，他們認為這是能讓工作做好、能開發出可信賴的軟體的唯一辦法。

我很抱歉讓你們失望。這些新出現的熱門技術很可能並不新。很可能只是一些曾經流行的技術的新的市場炒作。從另一方面講，你拋棄以前學到的所有東西，你改變以前的所有做法，你全面擁抱你學到的這個新的“唯一”的方法。事情不是這樣的。別這麼做。

做一個優秀的程式員就意味著你要學會妥協折中。這意味在A項目是你需要使用一種技術方案而在B項目上你需要使用另外一種。這意味這你需要在你的思路和老闆/客戶的要求之間做平衡。很多時候事情並不能做到雙方達成統一，但這並不意味著你該懊惱、痛斥為什麼不按你的思路去做。

真正重要的是，秉持自己的觀點，但柔軟的應用。

只有這樣，你才能走的更遠。