2、 簡單（simplicity）
保持代碼和設(shè)計盡可能簡單是系統(tǒng)可擴展性和可維護性的重要保障。關(guān)于Simple Design的討論可見徐X的Agile 101: Pair Programming & Simple Design 。kent beck用四個條件定義了簡單的系統(tǒng)代碼：運行所有的測試獲得通過、意圖明確、沒有重復(fù)、使用盡可能少的類和方法。我和accompanier也一直在向這個目標努力。
3、 反饋（feedback）
沒有持續(xù)的反饋，敏捷將無從談起。customer、accompanier、team以及test result的反饋給我們向用戶交付真正需要的系統(tǒng)提供了保證。我們的BA每天和客戶溝通，掌握用戶真正、迫切需要的功能和需求。由于我們的系統(tǒng)是一周發(fā)布一次，所以客戶也能在很短的時間內(nèi)知道完成的新功能，并及時提出改進意見和建議（其實客戶的需求也是一直不停地在變的）。
4、 勇氣（courage）
為了使代碼更加清晰、質(zhì)量更好，對工作代碼進行大范圍的修改和重構(gòu)需要勇氣，把某些代碼徹底拋棄需要勇氣，告訴客戶無法再添加新功能需要勇氣。我和accompanier目前都還有這樣的勇氣，希望系統(tǒng)越來越大、代碼越來越多的時候還有這樣的勇氣。
三、測試驅(qū)動開發(fā)（TDD）
關(guān)于TDD我們一直在嘗試尋找更爽的方法，目前采用的是webwork、spring、hibernate的組合框架，在大腦里無意識的已經(jīng)存在了三層結(jié)構(gòu)，我覺得采用TDD，這三層結(jié)構(gòu)應(yīng)該是最后被驅(qū)動出來產(chǎn)生的，而不是一開始就定好三層，然后再TDD編碼。
我們目前是分別對每層進行TDD，還是覺得service層驅(qū)動最有成就感，看到green bar 就令人興奮，action層老是mock來mock去的走流程實在屬沒啥意思。
最近又看到了使用Selenium和Castle進行測試驅(qū)動開發(fā) ，本想采納，但是使用Selenium進行至頂向下的驅(qū)動的話通過一個測試所需的時間太長了，我是對green bar有點上癮了的人，不能忍受那么長時間的red bar，懷疑它會對偶的身心健康造成影響，所以就作罷，還是由底至上的方法使測試通過的實踐最短，不知道各位對這樣的三層結(jié)構(gòu)是怎么TDD的？
Robert C. Martin大叔的TDD三條軍規(guī)如下：
1.除非這能讓失敗的單元測試通過，否則不允許去編寫任何的產(chǎn)品代碼。
2.只允許編寫剛好能夠?qū)е率〉膯卧獪y試。 （編譯失敗也屬于一種失敗）
3.只允許編寫剛好能夠?qū)е乱粋�失敗的單元測試通過的產(chǎn)品代碼。
對于任何功能，一定要從編寫它的單元測試開始；但是到了原則2，你就不能再為那個單元測試寫更多內(nèi)容。只要一出現(xiàn)該單元測試代碼編譯失敗，或是斷言失敗，你就必須停下來開始編寫產(chǎn)品代碼；但是到了原則3，你就只能編寫產(chǎn)品代碼，直到讓測試編譯成功或通過斷言為準。
此文章共有3頁 上一頁 1 2 3 下一頁
文章來源：中國項目管理資源網(wǎng)
|
Leadge.com首頁 > 知識庫 
