極限編程XP的關鍵實踐(一)提到 XP 的關鍵實踐，就不得不拿出下面這張圖。 看著眼熟不？是不是很多內(nèi)容我們在上篇文章中其實都已經(jīng)講過了。沒錯，可能有些概念你很清楚，但有些概念你就完全沒聽說過了。今天，我們就來一次性地好好學習一下。 看到圖中的每一環(huán)了嗎？最里面的是編程方法相關的，中間的是小組實踐相關的，最外面的是交付和管理相關的，我們就從內(nèi)到外逐一學習。 編程方法（一）：結對編程一提到結對編程，估計寫代碼的人都會很感興趣。但是轉(zhuǎn)念一想：倆人一臺電腦，一個寫一個看，這個畫風是不是有點兒曖昧...咳，這個如果是寫代碼還好，要是看一些別的什么不好的東西就真的很容易出事了，畢竟我們碼農(nóng)的口味是不好拿捏的。好吧，說正事，兩個人一起寫一份代碼，感覺是很大的浪費呀！確實，也有很多人質(zhì)疑，而且你在國內(nèi)不管大小公司，很少能見到真正地實現(xiàn)結對編程的公司。為什么呢？主要就是因為這種做法不太適合我們現(xiàn)在越來越卷的國內(nèi)的互聯(lián)網(wǎng)行業(yè)，畢竟我們是需要通過不停地加班 996 來實現(xiàn)一個人當兩個人用的，怎么可能讓兩個人去干一件事，這明顯違背老板的價值觀呀。 不過，敏捷實踐者們既然提出了這個做法，那么也一定是有它的可取之處的。比如：
其它還有一些優(yōu)點就不一一列舉了。咋眼一看，貌似還不錯呀，不過就像前面所說的，在國內(nèi)，或許有一些極限編程愛好者開的公司會用到，但大部分公司，或者說 99% 的公司中你都見不到。 編程方法（二）：測試驅(qū)動開發(fā)（TDD）想必這個對各位碼農(nóng)來說也不陌生吧，從我們寫代碼的角度來說，就是先寫測試再寫代碼，然后讓我們的代碼通過測試之后才算是完成開發(fā)。典型的框架就是各種單元測試框架，什么 JUnit、PHPUnit 之類的。這個吧，說實話，我這些年的開發(fā)之路上，也沒用到過。為什么呢？還是一點，效率略低。不過，這種開發(fā)方式最后做出來的產(chǎn)品的質(zhì)量的確是沒話說的。 當然，要使用 TDD 也是有前提的，第一當然是領導和團隊的支持，第二就是團隊的編碼規(guī)范完善，第三就是整體水平還不能太次。因為如果你一開始就把測試寫錯了，那么寫出來的代碼也不可能對。另外，如果濫用這些單元測試的話，還會讓人走向極端，追求完美的 100% 的測試覆蓋率，這也是不可取的。大部分情況下，從 60 分到 80 分，我們可能付出 100 分的努力就可以達到，而從 80 分到 95 分，可能需要付出 500 分的努力。但是從 95 分到 99 分，可能就需要 100000 分的努力，而 99 到 100 ，則有可能是 10 的 N 次方的努力了。當我們陷入到這種情況的時候，往往就會得不償失。 TDD 最核心的是去測什么東西呢？在 單元測試 階段，最需要測的是核心的算法，比如電商項目中的折扣金額之類的計算，返點優(yōu)惠的計算等。在代碼架構中，這些往往是服務層要解決的問題，所以，我們主要測試的目標應該是服務層的代碼。 再從分層架構上來說，控制層分發(fā)請求，接收參數(shù)，做好效驗方面的測試即可。模型層處理數(shù)據(jù)持久化，一定要注意入庫數(shù)據(jù)的安全性和完整性，做好這方面的測試即可。而服務層，也就是我們公共的計算部分，承擔著整個系統(tǒng)的核心，這些才是單元測試真正需要關心的地方。因此，和上方的結論一致，我們最重要的測試內(nèi)容就是服務層的核心算法或核心邏輯。 當然，你也可以在控制層寫服務，也可以在模型層寫服務，總之，找出關鍵核心的處理業(yè)務邏輯和算法的地方，加強這個地方的測試覆蓋率，不要盲目的以整體的測試覆蓋率為標準，這才是 TDD 能夠更好運用的重要方面。 理論歸理論，這方面其實我并沒有太多的實戰(zhàn)經(jīng)驗，不過我也覺得測試覆蓋率不能說明一切，在這里更希望有經(jīng)驗的同學能夠分享相關的經(jīng)驗，可以評論里留鏈接或者加好友轉(zhuǎn)載文章哦！ 編程方法（三）：重構這個詞對于寫代碼的人來說就更不陌生了，甚至很多人在換到新的公司時，第一個建議就是咱們重構一下老項目的代碼吧，因為前人寫得太X了。當然，想法總是好的，但現(xiàn)實其實是很殘酷的，真正的重構不是說我們要讓所有的代碼都變成你喜歡的代碼。真正的重構是源于敏捷的不斷迭代的重構。在收下兩種情況下，我們通常會開始重構一段代碼。
在重構中，有一個重要的概念就是 Don't Repect Your Self 也就是非常出名的 DRY 原則。從開發(fā)的角度來說，就是不要讓一段相同的代碼出現(xiàn)兩次。另外，重構還和 XP 中的其它元素緊密相關，比如說代碼集體所有制，讓代碼共享所有人都能看到代碼，并且通過結對編程，你的重構也會被別人發(fā)現(xiàn)并指出優(yōu)劣。需要完善的測試驅(qū)動開發(fā)機制，這樣才能確保你的重構不會帶來問題。簡單的設計，會讓你在重構的過程中關注最核心的部分，寫出能夠?qū)崿F(xiàn)功能的最簡單的代碼。 通過上述內(nèi)容，其實我們也就保證了 XP 中 勇氣 的含義，讓你能夠勇敢的去重構。 編程方法（四）：簡單設計還記得 XP 核心思想中的 簡單 原則嗎？沒錯，設計是很重要，但是，我們應該從最簡單的設計開始，通過迭代和增量不斷地完善它，而不是一開始就做出一個復雜的設計來。對于簡單來說，并不是說所有的設計都很小，只是說我們需要的是盡可能簡單的設計它，讓它盡快跑起來，通過持續(xù)發(fā)布來不斷驗證和完善。 之前聽說過一個故事，也是程序員間的笑話。一個公司上來就是各種高精尖的技術，各種高并發(fā)的處理，引入了一大堆阿里、騰訊的功能架構實踐。結果呢？每日最高只有可憐的幾百日活。而這個項目做了多久呢？幾百人的開發(fā)團隊，一年的開發(fā)時間，最后不了了之。 還好，目前大部分公司都不會再干這種事。甚至很多公司都會以 MVP(最小可行版本) 的形式來進行新項目的開發(fā)。這是好事，也是值得提倡的。那么，在 XP 中，對于簡單設計有什么建議嗎？
小組實踐（一）：持續(xù)集成持續(xù)集成也是我們碼農(nóng)們經(jīng)常聽到的一個名詞，甚至不少人也使用并實踐過 Jenkins 、Travis CI 這類的持續(xù)集成工具。但是你知道嗎？這些工具的誕生也正是因為受到 XP 的影響。 持續(xù)集成的關鍵點是什么？不斷的編譯整合代碼，在你將代碼提交到 Git 的時候，測試環(huán)境就開始進行單元測試，如果沒有通過，那么會報出異常，如果通過了，就會直接打包代碼。這樣就可以使代碼隨時保持在可以發(fā)布的狀態(tài)。因此，隨時整合，越頻繁越好，集成及測試過程的自動化程度越高越好，這就是持續(xù)集成的根本概念。 一般在自營業(yè)務的公司，都會有一個固定的代碼上線時間，快一點的可能是每周一次。而持續(xù)集成期望達到的最低標準是每日集成，也就是每日都能讓代碼進行上線。當然，依托現(xiàn)代化的這些持續(xù)集成工具，其實我們真的可以做到隨時提交隨時集成并上線。 小組實踐（二）：隱喻初看 隱喻 這個詞感覺很神秘呀，這個玩意是什么意思呢？比較官方的解釋是 “隱喻是一種語言表達手段，它用來暗示字面意義不相似的事物之間的相似之處”，用俗語來說，就是將設計模型、開發(fā)模式這些關鍵概念抽象化為一些比喻。就像一個經(jīng)典的說法，你能給一個完全不懂軟件開發(fā)的人講明白數(shù)據(jù)庫是干什么的一樣，在這其中，相信你也會使用很多的比喻。比如說，數(shù)據(jù)庫就是一個書店，我們要從這個書店中一個個的書架上找到想要書的，等等等。 在 XP 中，隱喻的作用主要是加強客戶和程序員之間的相互理解，消化積累知識，指導設計的開發(fā)方向。具體來說，它可以幫助我們：
總結今天的內(nèi)容多嗎？還好吧，因為我們的 XP 關鍵實踐有 13 個呢，后面還有一篇文章要繼續(xù)學習的。不知道大家發(fā)現(xiàn)沒有，XP 的實踐完全是和軟件開發(fā)密切相關的，這也沒辦法，畢竟 Kent Back 本身就是一名軟件大師。你知道嗎？設計模式實踐的先行者、《重構》作者 Martin Fowler 的好友同時也為這本書提供了不少內(nèi)容、XP 和 TDD（JUnit） 的創(chuàng)始人，這一堆名頭說的都是他。大家別急，下篇文章我們將繼續(xù)膜拜大師的作品，繼續(xù)我們的 XP 之路。 參考文檔： 《某培訓機構教材》 《用戶故事與敏捷方法》 《高效通過PMI-ACP考試（第2版）》 《敏捷項目管理與PMI-ACP應試指南》 、 |
|
|
來自： 硬核項目經(jīng)理 > 《待分類》
