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