極限編程XP的關(guān)鍵實(shí)踐(一)

提到 XP 的關(guān)鍵實(shí)踐，就不得不拿出下面這張圖。

看著眼熟不？是不是很多內(nèi)容我們?cè)谏掀恼轮衅鋵?shí)都已經(jīng)講過(guò)了。沒錯(cuò)，可能有些概念你很清楚，但有些概念你就完全沒聽說(shuō)過(guò)了。今天，我們就來(lái)一次性地好好學(xué)習(xí)一下。

看到圖中的每一環(huán)了嗎？最里面的是編程方法相關(guān)的，中間的是小組實(shí)踐相關(guān)的，最外面的是交付和管理相關(guān)的，我們就從內(nèi)到外逐一學(xué)習(xí)。

編程方法（一）：結(jié)對(duì)編程

一提到結(jié)對(duì)編程，估計(jì)寫代碼的人都會(huì)很感興趣。但是轉(zhuǎn)念一想：倆人一臺(tái)電腦，一個(gè)寫一個(gè)看，這個(gè)畫風(fēng)是不是有點(diǎn)兒曖昧...咳，這個(gè)如果是寫代碼還好，要是看一些別的什么不好的東西就真的很容易出事了，畢竟我們碼農(nóng)的口味是不好拿捏的。好吧，說(shuō)正事，兩個(gè)人一起寫一份代碼，感覺是很大的浪費(fèi)呀！確實(shí)，也有很多人質(zhì)疑，而且你在國(guó)內(nèi)不管大小公司，很少能見到真正地實(shí)現(xiàn)結(jié)對(duì)編程的公司。為什么呢？主要就是因?yàn)檫@種做法不太適合我們現(xiàn)在越來(lái)越卷的國(guó)內(nèi)的互聯(lián)網(wǎng)行業(yè)，畢竟我們是需要通過(guò)不停地加班 996 來(lái)實(shí)現(xiàn)一個(gè)人當(dāng)兩個(gè)人用的，怎么可能讓兩個(gè)人去干一件事，這明顯違背老板的價(jià)值觀呀。

不過(guò)，敏捷實(shí)踐者們既然提出了這個(gè)做法，那么也一定是有它的可取之處的。比如：

• 所有的決定都不是一個(gè)人做出的

• 至少有兩個(gè)人熟悉系統(tǒng)的每一部分

• 幾乎不可能有 2 個(gè)人都忽視的測(cè)試或其它任務(wù)

• 改變組合對(duì)象（也就是換不同的人結(jié)對(duì)）可以讓知識(shí)在組織內(nèi)更好地傳播

• 代碼總在被審查

• 結(jié)對(duì)編程的效率比單獨(dú)編程更高

其它還有一些優(yōu)點(diǎn)就不一一列舉了。咋眼一看，貌似還不錯(cuò)呀，不過(guò)就像前面所說(shuō)的，在國(guó)內(nèi)，或許有一些極限編程愛好者開的公司會(huì)用到，但大部分公司，或者說(shuō) 99% 的公司中你都見不到。

編程方法（二）：測(cè)試驅(qū)動(dòng)開發(fā)（TDD）

想必這個(gè)對(duì)各位碼農(nóng)來(lái)說(shuō)也不陌生吧，從我們寫代碼的角度來(lái)說(shuō)，就是先寫測(cè)試再寫代碼，然后讓我們的代碼通過(guò)測(cè)試之后才算是完成開發(fā)。典型的框架就是各種單元測(cè)試框架，什么 JUnit、PHPUnit 之類的。這個(gè)吧，說(shuō)實(shí)話，我這些年的開發(fā)之路上，也沒用到過(guò)。為什么呢？還是一點(diǎn)，效率略低。不過(guò)，這種開發(fā)方式最后做出來(lái)的產(chǎn)品的質(zhì)量的確是沒話說(shuō)的。

當(dāng)然，要使用 TDD 也是有前提的，第一當(dāng)然是領(lǐng)導(dǎo)和團(tuán)隊(duì)的支持，第二就是團(tuán)隊(duì)的編碼規(guī)范完善，第三就是整體水平還不能太次。因?yàn)槿绻阋婚_始就把測(cè)試寫錯(cuò)了，那么寫出來(lái)的代碼也不可能對(duì)。另外，如果濫用這些單元測(cè)試的話，還會(huì)讓人走向極端，追求完美的 100% 的測(cè)試覆蓋率，這也是不可取的。大部分情況下，從 60 分到 80 分，我們可能付出 100 分的努力就可以達(dá)到，而從 80 分到 95 分，可能需要付出 500 分的努力。但是從 95 分到 99 分，可能就需要 100000 分的努力，而 99 到 100 ，則有可能是 10 的 N 次方的努力了。當(dāng)我們陷入到這種情況的時(shí)候，往往就會(huì)得不償失。

TDD 最核心的是去測(cè)什么東西呢？在 單元測(cè)試 階段，最需要測(cè)的是核心的算法，比如電商項(xiàng)目中的折扣金額之類的計(jì)算，返點(diǎn)優(yōu)惠的計(jì)算等。在代碼架構(gòu)中，這些往往是服務(wù)層要解決的問(wèn)題，所以，我們主要測(cè)試的目標(biāo)應(yīng)該是服務(wù)層的代碼。

再?gòu)姆謱蛹軜?gòu)上來(lái)說(shuō)，控制層分發(fā)請(qǐng)求，接收參數(shù)，做好效驗(yàn)方面的測(cè)試即可。模型層處理數(shù)據(jù)持久化，一定要注意入庫(kù)數(shù)據(jù)的安全性和完整性，做好這方面的測(cè)試即可。而服務(wù)層，也就是我們公共的計(jì)算部分，承擔(dān)著整個(gè)系統(tǒng)的核心，這些才是單元測(cè)試真正需要關(guān)心的地方。因此，和上方的結(jié)論一致，我們最重要的測(cè)試內(nèi)容就是服務(wù)層的核心算法或核心邏輯。

當(dāng)然，你也可以在控制層寫服務(wù)，也可以在模型層寫服務(wù)，總之，找出關(guān)鍵核心的處理業(yè)務(wù)邏輯和算法的地方，加強(qiáng)這個(gè)地方的測(cè)試覆蓋率，不要盲目的以整體的測(cè)試覆蓋率為標(biāo)準(zhǔn)，這才是 TDD 能夠更好運(yùn)用的重要方面。

理論歸理論，這方面其實(shí)我并沒有太多的實(shí)戰(zhàn)經(jīng)驗(yàn)，不過(guò)我也覺得測(cè)試覆蓋率不能說(shuō)明一切，在這里更希望有經(jīng)驗(yàn)的同學(xué)能夠分享相關(guān)的經(jīng)驗(yàn)，可以評(píng)論里留鏈接或者加好友轉(zhuǎn)載文章哦！

編程方法（三）：重構(gòu)

這個(gè)詞對(duì)于寫代碼的人來(lái)說(shuō)就更不陌生了，甚至很多人在換到新的公司時(shí)，第一個(gè)建議就是咱們重構(gòu)一下老項(xiàng)目的代碼吧，因?yàn)榍叭藢懙锰玐了。當(dāng)然，想法總是好的，但現(xiàn)實(shí)其實(shí)是很殘酷的，真正的重構(gòu)不是說(shuō)我們要讓所有的代碼都變成你喜歡的代碼。真正的重構(gòu)是源于敏捷的不斷迭代的重構(gòu)。在收下兩種情況下，我們通常會(huì)開始重構(gòu)一段代碼。

1. 實(shí)現(xiàn)某個(gè)特性之前：嘗試改變現(xiàn)有的代碼結(jié)構(gòu)，以使得實(shí)現(xiàn)新的特性更加容易

2. 實(shí)現(xiàn)特性之后：檢查剛剛寫完的代碼后，看是否能夠進(jìn)一步的優(yōu)化

在重構(gòu)中，有一個(gè)重要的概念就是 Don't Repect Your Self 也就是非常出名的 DRY 原則。從開發(fā)的角度來(lái)說(shuō)，就是不要讓一段相同的代碼出現(xiàn)兩次。另外，重構(gòu)還和 XP 中的其它元素緊密相關(guān)，比如說(shuō)代碼集體所有制，讓代碼共享所有人都能看到代碼，并且通過(guò)結(jié)對(duì)編程，你的重構(gòu)也會(huì)被別人發(fā)現(xiàn)并指出優(yōu)劣。需要完善的測(cè)試驅(qū)動(dòng)開發(fā)機(jī)制，這樣才能確保你的重構(gòu)不會(huì)帶來(lái)問(wèn)題。簡(jiǎn)單的設(shè)計(jì)，會(huì)讓你在重構(gòu)的過(guò)程中關(guān)注最核心的部分，寫出能夠?qū)崿F(xiàn)功能的最簡(jiǎn)單的代碼。

通過(guò)上述內(nèi)容，其實(shí)我們也就保證了 XP 中 勇氣 的含義，讓你能夠勇敢的去重構(gòu)。

編程方法（四）：簡(jiǎn)單設(shè)計(jì)

還記得 XP 核心思想中的 簡(jiǎn)單 原則嗎？沒錯(cuò)，設(shè)計(jì)是很重要，但是，我們應(yīng)該從最簡(jiǎn)單的設(shè)計(jì)開始，通過(guò)迭代和增量不斷地完善它，而不是一開始就做出一個(gè)復(fù)雜的設(shè)計(jì)來(lái)。對(duì)于簡(jiǎn)單來(lái)說(shuō)，并不是說(shuō)所有的設(shè)計(jì)都很小，只是說(shuō)我們需要的是盡可能簡(jiǎn)單的設(shè)計(jì)它，讓它盡快跑起來(lái)，通過(guò)持續(xù)發(fā)布來(lái)不斷驗(yàn)證和完善。

之前聽說(shuō)過(guò)一個(gè)故事，也是程序員間的笑話。一個(gè)公司上來(lái)就是各種高精尖的技術(shù)，各種高并發(fā)的處理，引入了一大堆阿里、騰訊的功能架構(gòu)實(shí)踐。結(jié)果呢？每日最高只有可憐的幾百日活。而這個(gè)項(xiàng)目做了多久呢？幾百人的開發(fā)團(tuán)隊(duì)，一年的開發(fā)時(shí)間，最后不了了之。

還好，目前大部分公司都不會(huì)再干這種事。甚至很多公司都會(huì)以 MVP(最小可行版本) 的形式來(lái)進(jìn)行新項(xiàng)目的開發(fā)。這是好事，也是值得提倡的。那么，在 XP 中，對(duì)于簡(jiǎn)單設(shè)計(jì)有什么建議嗎？

1. 編寫測(cè)試代碼

2. 保持每個(gè)類只負(fù)責(zé)一件事（單一職責(zé)原則）

3. 迪米特法則（最少知識(shí)原則）

4. DRY 原則

5. 簡(jiǎn)單的設(shè)計(jì)需要簡(jiǎn)單的思考，要有勇于重構(gòu)的勇氣和定期重構(gòu)的習(xí)慣

小組實(shí)踐（一）：持續(xù)集成

持續(xù)集成也是我們碼農(nóng)們經(jīng)常聽到的一個(gè)名詞，甚至不少人也使用并實(shí)踐過(guò) Jenkins 、Travis CI 這類的持續(xù)集成工具。但是你知道嗎？這些工具的誕生也正是因?yàn)槭艿?XP 的影響。

持續(xù)集成的關(guān)鍵點(diǎn)是什么？不斷的編譯整合代碼，在你將代碼提交到 Git 的時(shí)候，測(cè)試環(huán)境就開始進(jìn)行單元測(cè)試，如果沒有通過(guò)，那么會(huì)報(bào)出異常，如果通過(guò)了，就會(huì)直接打包代碼。這樣就可以使代碼隨時(shí)保持在可以發(fā)布的狀態(tài)。因此，隨時(shí)整合，越頻繁越好，集成及測(cè)試過(guò)程的自動(dòng)化程度越高越好，這就是持續(xù)集成的根本概念。

一般在自營(yíng)業(yè)務(wù)的公司，都會(huì)有一個(gè)固定的代碼上線時(shí)間，快一點(diǎn)的可能是每周一次。而持續(xù)集成期望達(dá)到的最低標(biāo)準(zhǔn)是每日集成，也就是每日都能讓代碼進(jìn)行上線。當(dāng)然，依托現(xiàn)代化的這些持續(xù)集成工具，其實(shí)我們真的可以做到隨時(shí)提交隨時(shí)集成并上線。

小組實(shí)踐（二）：隱喻

初看 隱喻 這個(gè)詞感覺很神秘呀，這個(gè)玩意是什么意思呢？比較官方的解釋是 “隱喻是一種語(yǔ)言表達(dá)手段，它用來(lái)暗示字面意義不相似的事物之間的相似之處”，用俗語(yǔ)來(lái)說(shuō)，就是將設(shè)計(jì)模型、開發(fā)模式這些關(guān)鍵概念抽象化為一些比喻。就像一個(gè)經(jīng)典的說(shuō)法，你能給一個(gè)完全不懂軟件開發(fā)的人講明白數(shù)據(jù)庫(kù)是干什么的一樣，在這其中，相信你也會(huì)使用很多的比喻。比如說(shuō)，數(shù)據(jù)庫(kù)就是一個(gè)書店，我們要從這個(gè)書店中一個(gè)個(gè)的書架上找到想要書的，等等等。

在 XP 中，隱喻的作用主要是加強(qiáng)客戶和程序員之間的相互理解，消化積累知識(shí)，指導(dǎo)設(shè)計(jì)的開發(fā)方向。具體來(lái)說(shuō)，它可以幫助我們：

1. 尋求共識(shí)

2. 發(fā)明共享詞匯（屬于我們團(tuán)隊(duì)與客戶交流的詞典）

3. 創(chuàng)新的重要手段（有時(shí)候恰當(dāng)?shù)谋扔髂軌蚣ぐl(fā)更多的靈感）

4. 描述體系結(jié)構(gòu)（讓抽象的概念更加好理解）

總結(jié)

今天的內(nèi)容多嗎？還好吧，因?yàn)槲覀兊?XP 關(guān)鍵實(shí)踐有 13 個(gè)呢，后面還有一篇文章要繼續(xù)學(xué)習(xí)的。不知道大家發(fā)現(xiàn)沒有，XP 的實(shí)踐完全是和軟件開發(fā)密切相關(guān)的，這也沒辦法，畢竟 Kent Back 本身就是一名軟件大師。你知道嗎？設(shè)計(jì)模式實(shí)踐的先行者、《重構(gòu)》作者 Martin Fowler 的好友同時(shí)也為這本書提供了不少內(nèi)容、XP 和 TDD（JUnit） 的創(chuàng)始人，這一堆名頭說(shuō)的都是他。大家別急，下篇文章我們將繼續(xù)膜拜大師的作品，繼續(xù)我們的 XP 之路。

參考文檔：

《某培訓(xùn)機(jī)構(gòu)教材》

《用戶故事與敏捷方法》

《高效通過(guò)PMI-ACP考試（第2版）》

《敏捷項(xiàng)目管理與PMI-ACP應(yīng)試指南》