在軟體開發的過程中，有沒有方法可以避免我們浪費心力在無謂的堅持上，然後用比較簡單而又有效率的方式來完成我們的工作呢？經過與同事上面的對話，同人想到運用到我在分享會中所提到的觀念與實務，可以很輕易地掌握設計演進的節奏。藉由此篇文章分享出來，也算當做同人在 1/9 敏捷開發分享會後的一個註腳吧。
有沒有比較生活化的例子可以用來隱喻測試驅動開發和重構呢？同人覺得用最近我們搬家整理房間的經驗，正好可以隱喻這些實務的開發方法。
敏捷開發並不是教條式的照本宣科，開發者要懂得變通最重要的是用心思考，而非把必要的思考都看成精神層面的問題，這並非適用於敏捷開發的心智模式。以下是同人在 Facebook 的 Scrum community in Taiwan 的回應，但文辭有略為做過一番修飾，可以用來澄清我對測試驅動開發步驟的看法。
對 David Ko 提出 Kent 認為 Red/green/refactor 是 TDD 的三字箴言的說法，同人倒是覺得有探討的必要。以下分享我在 Facebook 回應 David Ko 的觀點，這些觀點應該可以解釋為什麼測試開發不需要徹底重構；其實重構並不是問題，而是到底什麼叫做徹底？而且如果 TDD 可以徹底重構，那麼一開始就可以讓設計一次到位，那寫好的測試程式以後也用不著了，不正是多此一舉？
測試驅動開發的精神，不應該用一般機械論的觀點來進行工作或任務的化約，而是基於複雜理論的重要觀念；維持穩定與變化的動態平衡，不在於掌握系統核心而在於邊緣，讓變動限定在人們可以掌握的範圍內，這或許才是測試驅動開發最關鍵的精神吧！
分享會在台北市電腦公會舉行，看到現場互動氣氛的熱絡，以及會後學員們給予不少正面的評價，感覺大家收穫都不少。其實包括我自己在分享會結束之後也產生了一些想法，倒是想藉由此文章分享我的分享會後心得。
這篇文章是投稿 ZDNet Taiwan 的文章原稿，由 ZDNet Taiwan 以〈如何在系統異常前發現錯誤？〉、〈如何在系統異常前發現錯誤？（下）〉兩篇文章刊登。文章原稿未經 ZDNet Taiwan 編輯，內容可能與 ZDNet Taiwan 約略有所不同。 前一陣子有兩個與資訊系統失常有關，而且眾所矚目的新聞事件，也就是戴爾電腦網路購物系統與台北捷運內湖線的系統異常。相信很多人都認為這兩個系統會發生系統異常相當離譜，在系統上線之後才發現系統無法正常運作，造成系統使用者的困擾，同時也會讓人對系統可靠度與穩定度失去信心，而增加系統的失敗成本。 雖然平心而論，想要事前預料系統可能發生的問題，並加以預防或因應其實並不容易，因為開發系統，尤其是軟體開發常會碰到事先難以預料的問題。但如果能在錯誤造成危害之前，就能夠發現問題並採取適當的行動來解決它，應該就能減少系統的失敗成本。因此，看到戴爾與台北捷運內湖線的重大系統異常，讓筆者想探討如何在系統失敗前發現錯誤，以避免系統失敗的巨大損失。
是否代表系統開發追求速度與彈性，就必然犧牲文件與流程呢？同人認為這樣看就太過簡化了，系統開發的彈性並不是忽略系統文件與流程，而是只重視有實質效益的一切事物，當然包括文件與流程。
在台灣，品質最大的問題是人們習慣將品質流程獨立於設計及開發過程之外，以為兩者是可以完全分割的。然而這種思維對品質的結論就會是「把做好的東西丟到另一端去」，讓開發人員認為品質是品質部門的責任，而品質部門則認為提昇品質不是他們的責任，以為最多只能做到知道產品有問題，而不知道如何改善它們，只能退回到開發人員那邊來解決。
如果穩定的程式真的是偶然的，程式的穩定似乎只能依賴運氣而不是人為努力，事情真的是這樣嗎？其實這位噗友太過強調環境變化的隨機性，卻忽略了適應環境變化，程式開發必然會經歷複雜演化的過程。穩定的程式是演化而來的，雖然演化的過程是偶然、但其最後結果卻是必然。換句話說，穩定的程式是偶然下的必然。
最新迴響