# re: 測試驅(qū)動(dòng)開發(fā)（ＴＤＤ）的頓悟 2008-01-23 21:38 neoragex2002

用TDD做設(shè)計(jì)的人是爽了，寫測試一句話，多簡單。可想想你的團(tuán)隊(duì)呢？他們的創(chuàng)造熱情和成就感在哪里？他們的士氣在哪里？就幾個(gè)空而無物的測試用例？任何方法學(xué)正面地作用在主動(dòng)積極的人才會(huì)起作用。  回復(fù)  更多評(píng)論   

# re: 測試驅(qū)動(dòng)開發(fā)（ＴＤＤ）的頓悟 2008-01-23 21:49 eXile

@neoragex2002
這個(gè)老兄還是對(duì)ＴＤＤ有一個(gè)起碼的了解以后，再來討論這個(gè)問題吧。
  回復(fù)  更多評(píng)論   

# re: 測試驅(qū)動(dòng)開發(fā)（ＴＤＤ）的頓悟 2008-01-23 21:50 eXile

FROM JAVAEYE:
對(duì)于大多數(shù)的中國的軟件開發(fā)團(tuán)隊(duì)來說，難以實(shí)現(xiàn)敏捷的最重要問題是人的素質(zhì)問題。一個(gè)敏捷團(tuán)隊(duì)要求每個(gè)成員都有較好的OOP和OOD的能力。.......實(shí)現(xiàn)敏捷是一個(gè)漸進(jìn)的過程。構(gòu)造一個(gè)在技術(shù)上有敏捷能力的團(tuán)隊(duì)有兩種方法，一是用足夠的錢去招聘有足夠能力的程序員(大部分企業(yè)沒有那么多錢)。二是將現(xiàn)有不符合敏捷技術(shù)要求的程序員培養(yǎng)為合格的敏捷工作者。而在培養(yǎng)的路上，單元測試正是一個(gè)很好的驅(qū)動(dòng)方式和實(shí)踐平臺(tái)。  回復(fù)  更多評(píng)論   

# re: 測試驅(qū)動(dòng)開發(fā)（ＴＤＤ）的頓悟 2008-01-23 21:52 eXile

FROM JAVAEYE
就是因?yàn)椤拔臋n/注釋”在代碼的頻繁修改中太容易過時(shí)，而且也太容易為人所忘記，所以在我的實(shí)踐中不寫文檔，我的文檔就是我的“代碼+單元測試”，想知道我的想法，看“代碼+單元測試”就行了，沒有任何形式的文檔比“代碼+單元測試”更能體現(xiàn)我的設(shè)計(jì)
- 我們的文檔是十分簡短和松散的，一般放在wiki上，起到story guide的作用，但如上所說，隨著開發(fā)很快就過時(shí)了，從中你能找到設(shè)計(jì)的逐步迭代，但它和最終的產(chǎn)品是有差別的
- 對(duì)于我們開發(fā)工程師來講，“代碼+單元測試”就是我們的文檔，對(duì)于客戶來講，有專門的產(chǎn)品文檔供他們使用，但是那是由文檔工程師寫的   回復(fù)  更多評(píng)論   

# re: 測試驅(qū)動(dòng)開發(fā)（ＴＤＤ）的頓悟 2008-01-23 21:53 eXile

FROM JAVAEYE:
閱讀有些test case只能讓你云里霧里，而閱讀有些則讓你馬上就知道這段代碼的用途。其實(shí)找并不是這些test case寫的有水平差別，而往往是有針對(duì)問題角度的差別。而進(jìn)一步，你會(huì)發(fā)現(xiàn)閱讀這些test case如果按照一定順序，就會(huì)從最初的動(dòng)機(jī)到最終的實(shí)現(xiàn)細(xì)節(jié)都有一個(gè)清晰的理解，而如果我們能夠在寫這些test case的時(shí)候就標(biāo)注出這個(gè)理解順序，將是十分核算的。而實(shí)際上很多時(shí)候我們書寫的順序就是最終我們適于閱讀理解的順序。
  回復(fù)  更多評(píng)論   

# re: 測試驅(qū)動(dòng)開發(fā)（ＴＤＤ）的頓悟 2008-01-23 21:58 eXile

JAVAEYE上真是有不少明言警句啊, 看來都是高手。。。  回復(fù)  更多評(píng)論   

# re: 測試驅(qū)動(dòng)開發(fā)（ＴＤＤ）的頓悟 2008-01-23 22:01 eXile

FROM JAVAEYE:
就說注釋好了，比較一下：
1。可運(yùn)行的代碼
2。測試代碼的單元測試和其他測試
3。注釋

這個(gè)重要性應(yīng)該是向下遞減的。沒有1，其他都沒有意義了。沒有2，就沒有一種可執(zhí)行、可重復(fù)的方法來驗(yàn)證1的正確性。

至于注釋，對(duì)于程序的功能、正確性和可靠性，對(duì)于客戶來說是沒有任何意義的，所以除非有特殊的理由，我們才去寫注釋。

一般來說，堅(jiān)持寫注釋的人最重要的觀點(diǎn)是便于自己或后來者理解代碼，減小程序維護(hù)和變更的成本。這個(gè)我們當(dāng)然喜歡，但是要注意幾點(diǎn)：
1。注釋到底是不是最好的工具來加快和精確理解
2。達(dá)到這樣的目的需要多少成本

第一點(diǎn)，首先絕大多數(shù)注釋是細(xì)節(jié)程度上的，基本上和代碼本身處于同一層次，因此我們需要看一看代碼本身是否比注釋更有權(quán)利。
注釋的目的基本上是為了說明
1：代碼實(shí)現(xiàn)中的權(quán)衡
2。代碼本身的目的
3：別的代碼使用該代碼的方法

以Java舉例，注釋包括包注釋、類注釋和方法注釋。在99%的情況下，我認(rèn)為只有包注釋和類注釋才有意義，因?yàn)橐粋€(gè)包和
類只有自己的名字來解釋自己的含義，如果是一個(gè)簡單的類，譬如說是Rectangle，當(dāng)然這個(gè)名字已經(jīng)說明了一切。但很多時(shí)候，
一個(gè)類里面包含很多方法，很難簡單地用一個(gè)類名字來描述整個(gè)類的意圖和作用這個(gè)時(shí)候，這個(gè)時(shí)候代碼本身是不足的，需要類注釋的。

對(duì)于方法層次上的注釋，除非你這個(gè)方法用了非常復(fù)雜的算法，那么我們最先關(guān)注的是它的目的，這個(gè)目的用方法的名字就足夠了，
如果你認(rèn)為它有三個(gè)目的，或者有幾個(gè)階段，那你必須重構(gòu)，直到達(dá)到這個(gè)目標(biāo)。這里代碼比注釋的好處是能夠優(yōu)化代碼本身的結(jié)構(gòu)，
易于重用和新變化，沒有同步的成本，更重要的是它是可執(zhí)行的。

有的時(shí)候，例如內(nèi)部實(shí)現(xiàn)是錯(cuò)誤的，我們需要修改代碼，這個(gè)時(shí)候我們也需要理解這個(gè)代碼地實(shí)現(xiàn)方式，但我認(rèn)為一旦達(dá)到了上面的要求，對(duì)一個(gè)程序員來講，代碼更精確、更簡單地能夠被理解，而不是注釋，除非注釋逐行解釋代碼地實(shí)現(xiàn)。

至于別的代碼如何來使用你自己的代碼，我不由得回憶起當(dāng)初學(xué)習(xí)delphi地經(jīng)歷，在我使用一段delphi以后，我很多時(shí)候都是憑自己對(duì)delphi函數(shù)命名的習(xí)慣的猜測去調(diào)用一個(gè)個(gè)函數(shù)，而不是依靠delphi地API文檔和delphi源代碼里面的注釋（實(shí)際上非常少），真的無法理解就去看源代碼。而對(duì)于一些我完全是初學(xué)的類或者函數(shù)，我的做法首先是去尋找范例代碼理解函數(shù)調(diào)用的順序，至于這種理解是否正確
最終取決于我自己的不斷測試。對(duì)于一些復(fù)雜的方法，我會(huì)在基本已經(jīng)理解，并且能夠使用的情況下再去看是否還有別的什么"訣竅",后門等等。因此，在這方面單元測試無疑比注釋更有用，但是如果一個(gè)方法確實(shí)比較復(fù)雜，并且不同地類和函數(shù)之間有一定的依賴關(guān)系，我們需要專門的API文檔，注釋根本做不到這一點(diǎn)。

第二點(diǎn)，注釋的成本。注釋無法驗(yàn)證，注釋不能執(zhí)行。因此，注釋必須完全通過手工來進(jìn)行維護(hù)，當(dāng)一個(gè)類被重構(gòu)為一個(gè)類層次，
當(dāng)一個(gè)方法被抽取成兩個(gè)方法，當(dāng)一個(gè)類的某些方法被移到另一個(gè)類，一個(gè)類地實(shí)現(xiàn)被改變（接口不變）的時(shí)候我們都必須手工去維護(hù)
這些東西，并且無法知道我們的注釋到底是不是正確揭示了這個(gè)類、方法的意圖和實(shí)現(xiàn)思路。這個(gè)成本是非常高的，特別是當(dāng)我們
知道注釋既不能為客戶提高更多的價(jià)值，也不會(huì)對(duì)其他程序員理解代碼有多大的幫助。當(dāng)然，如果我們有足夠的人力、物力愿意干這樣的活，有些時(shí)候也會(huì)稍微有點(diǎn)幫助。
  回復(fù)  更多評(píng)論   

# re: 測試驅(qū)動(dòng)開發(fā)（ＴＤＤ）的頓悟 2008-01-23 22:02 eXile

FROM JAVAEYE:
實(shí)際上過多的注釋妨礙了重構(gòu)的進(jìn)行，如果你想讓代碼僵化那么就寫大量的注釋好了，越多越好，甚至注釋:代碼=10:1。重構(gòu)的結(jié)果往往是刪除掉大量的注釋，因?yàn)樗鼈兓蛘咭呀?jīng)不適合代碼當(dāng)前的結(jié)構(gòu)，或者已經(jīng)不再需要，因?yàn)榇a的結(jié)構(gòu)已經(jīng)非常清晰了。而且我并不知道是否還有可能進(jìn)行下一次重構(gòu)，那么我寫太多的注釋是不是很有可能是在做無用功？我其實(shí)只要寫很少量的注釋就足夠了。
  回復(fù)  更多評(píng)論   

# re: 測試驅(qū)動(dòng)開發(fā)（ＴＤＤ）的頓悟 2008-01-23 22:02 eXile

FROM JAVAEYE:
很多大公司的代碼都沒有任何注釋，很多大師寫代碼也沒有注釋（看看junit就知道了，大家可能不知道這個(gè)東西是兩個(gè)大師在飛機(jī)上試驗(yàn)結(jié)對(duì)編程的副產(chǎn)品）。原因在于他們根本就不能容忍任何注釋造成的味道。
  回復(fù)  更多評(píng)論   

# re: 測試驅(qū)動(dòng)開發(fā)（ＴＤＤ）的頓悟 2008-01-23 22:35 eXile

FROM JAVAEYE:
注釋與文檔的本質(zhì)，是為了便于軟件的開發(fā)和維護(hù)，而不是在一道一道的工序之間作為“交接班”的說明
  回復(fù)  更多評(píng)論   

# re: 測試驅(qū)動(dòng)開發(fā)（ＴＤＤ）的頓悟 2008-01-24 08:08 Enoch

測試驅(qū)動(dòng)開發(fā)(TEST DRIVER DEVELOP, TDD)是以測試為驅(qū)動(dòng)力，進(jìn)行開發(fā)，是一種開發(fā)方法。實(shí)際上也是極限編程(Extreme Programming, EP)的一個(gè)重要特點(diǎn)，TDD不斷的測試推動(dòng)代碼的開發(fā)，既簡化了代碼，又保證了軟件質(zhì)量。
使用測試驅(qū)動(dòng)開發(fā)(TDD)就是通過編寫代碼的測試用例，對(duì)其功能的分解、使用過程、接口都進(jìn)行了設(shè)計(jì)，以滿足軟件需求，這樣使得代碼的設(shè)計(jì)更符合后期開發(fā)的需求。
測試驅(qū)動(dòng)開發(fā)(TDD)開發(fā)通常需要明確要完成的功能，快速實(shí)現(xiàn)功能的測試用例，完成對(duì)代碼進(jìn)行重構(gòu)，測試完成所有功能的開發(fā)。這里要求測試的完全隔離，不同代碼的測試不應(yīng)該存在耦合。 測試驅(qū)動(dòng)開發(fā)(TDD)從某種意義上說是單元測試(Unit Test, UT)置于軟件過程的中心地位。
  回復(fù)  更多評(píng)論