敏捷開發(fā)修煉之道

最近看了一本叫高效程序員的45個(gè)習(xí)慣，下面總結(jié)內(nèi)容。

全書分為9個(gè)章節(jié)：

• 敏捷開發(fā)之道
• 態(tài)度決定一切
• 學(xué)無(wú)止境
• 交互用戶想要的軟件
• 敏捷反饋
• 敏捷編碼
• 敏捷調(diào)試
• 敏捷協(xié)作
• 尾聲：走向敏捷

第一章：敏捷開發(fā)之道

用原文的方法講，敏捷開發(fā)就是在一個(gè)高度協(xié)作的環(huán)境中，不斷地使用反饋進(jìn)行自我調(diào)整和完善。

我想其實(shí)和學(xué)習(xí)任何事情都是一樣的道理，實(shí)踐出真知，不斷地嘗試和反饋，糾正自己的錯(cuò)誤，這樣容易推動(dòng)進(jìn)度，有目標(biāo)性，效率也會(huì)更高。

第二章：態(tài)度決定一切

做事的態(tài)度非常重要，包括個(gè)人和團(tuán)隊(duì)。專業(yè)的態(tài)度應(yīng)該著眼于項(xiàng)目和團(tuán)隊(duì)的積極結(jié)果，關(guān)注個(gè)人和團(tuán)隊(duì)的成長(zhǎng)，圍繞最終的成功開展工作。

1.做事

反例：“出了問題，第一重要的是確定元兇。找到那個(gè)白癡！一旦證實(shí)了是他的錯(cuò)誤，就可以保證這樣的問題永遠(yuǎn)不會(huì)再發(fā)生了”。

這個(gè)錯(cuò)誤的觀點(diǎn)很滑稽，但是從生活中也經(jīng)常發(fā)現(xiàn)這種態(tài)度，比如出錯(cuò)了大家第一件事情就是找是誰(shuí)的錯(cuò)，而不是想著解決問題的方法。

正確的做法：“把矛頭對(duì)準(zhǔn)問題的解決方法，而不是人。這是真正有用處的正面效應(yīng)”。

勇于承認(rèn)自己不知道的答案，這樣讓人感覺放心，一個(gè)重大的錯(cuò)誤應(yīng)該被視為一個(gè)學(xué)習(xí)而不是指責(zé)他人的機(jī)會(huì)。

平衡的藝術(shù)：

• “這不是我的錯(cuò)”，這句話不對(duì)?！斑@都是你的錯(cuò)”，更不對(duì)
• 如果你沒犯過任何錯(cuò)誤，那么說(shuō)明你可能沒有努力去工作（真是有道理！??！哈哈）
• 開發(fā)者和質(zhì)量工程師爭(zhēng)論某個(gè)問題是系統(tǒng)本身缺陷還是系統(tǒng)增強(qiáng)功能導(dǎo)致的，通常沒什么意義，還不如趕緊去修復(fù)它
• 如果一個(gè)團(tuán)隊(duì)成員誤解了一個(gè)需求、一個(gè)API，那么其他人可能也有相同誤解
• 如果一個(gè)成員一再傷害團(tuán)隊(duì)，則他表現(xiàn)得很不職業(yè)，應(yīng)該開掉他
• 如果大部分成員（尤其開發(fā)領(lǐng)導(dǎo)者）行為不職業(yè)，并且他們對(duì)團(tuán)隊(duì)目標(biāo)都不感興趣，你就應(yīng)該離開這個(gè)團(tuán)隊(duì)

2.欲速則不達(dá)

反例：“你不需要真正理解那塊代碼，它只要能夠工作就可以了。哦，只要在結(jié)果中加幾行代碼，他就可以工作了，干吧！就把那幾行加進(jìn)去，它應(yīng)該可以工作”。

經(jīng)常會(huì)遇到這種情況，出現(xiàn)一個(gè)bug，時(shí)間緊迫，通過加一行代碼或者忽略那個(gè)列表最后一個(gè)條目，就可以工作（好像我也干過，欲哭無(wú)淚！！！）。但是接下來(lái)做法才能說(shuō)明，誰(shuí)是優(yōu)秀程序員，誰(shuí)是拙劣碼農(nóng)：

• 拙劣代碼工人會(huì)不假思索完成改寫，然后轉(zhuǎn)向下一個(gè)問題；
• 優(yōu)秀程序員會(huì)盡力去理解為什么這里+1，更重要是去想明白會(huì)產(chǎn)生說(shuō)明其他影響；

因此，最好做到：

• 不要孤立地編碼，實(shí)行代碼復(fù)審，有利于代碼更好理解和發(fā)現(xiàn)bug；
• 使用單元測(cè)試，項(xiàng)目可以分成更好管理的小塊，還能直接閱讀單元測(cè)試文檔，更有利于理解代碼模塊，運(yùn)行和使用代碼；

平衡的藝術(shù)：

• 必須理解每一塊的代碼如何工作，但不需要成為專家，只要能夠使用它有效工作就夠了；
• 如果有成員宣布，某塊代碼其他人很難看懂，那么意味著任何人都很難維護(hù)它，需要修改它；
• 不要急于修復(fù)一段沒有真正理解的代碼；
• 對(duì)于大型系統(tǒng)，除了深入正在開發(fā)的模塊，還需要從更高層了解大部分模塊功能，理解系統(tǒng)各個(gè)功能塊之間的交互

3.對(duì)事不對(duì)人

一個(gè)例子，當(dāng)某人正在做一個(gè)新方案介紹時(shí)，下面有人說(shuō)：“那樣很蠢！”（也就暗示開發(fā)者也蠢），改進(jìn)一下“那樣很蠢，你忘記考慮它要線程安全?！?，而最佳表達(dá)方式是：“謝謝，xx，但是我想知道，兩個(gè)用戶同時(shí)登錄會(huì)發(fā)生什么情況？”

三種方式對(duì)應(yīng)三種含義：

• 否定個(gè)人能力
• 指出明顯缺點(diǎn)，并否定其觀點(diǎn)
• 詢問你的隊(duì)友，并提出你的顧慮

對(duì)于團(tuán)隊(duì)決策需要做一下特殊技術(shù)：

• 設(shè)定最終期限，沒有最好的方案，只有最好，在決策為難時(shí)，必須做出決策；
• 逆向思維，客觀對(duì)待問題：先積極看到它的正面，然后再努力從反面去認(rèn)識(shí)它；
• 設(shè)立仲裁人，仲裁人保證每個(gè)人都有發(fā)言機(jī)會(huì)，防止被明星員工操縱會(huì)議，及時(shí)打斷假大空發(fā)言，如果沒有積極參加這次討論，你最好就退一步做會(huì)議監(jiān)督者（咦，當(dāng)我對(duì)問題不了解的時(shí)候，好像就是這么干的）；
• 支持已經(jīng)做出的決定，無(wú)論誰(shuí)定的方案，團(tuán)隊(duì)?wèi)?yīng)該都努力完成，而不是關(guān)心誰(shuí)的主意

4.排除萬(wàn)難，奮勇前進(jìn)

發(fā)現(xiàn)某段代碼太骯臟了，應(yīng)該講糟糕的代碼放到一邊，立刻重寫。并且列出重寫的理由，幫助你的老板和同事認(rèn)清形勢(shì)，并得到正確的解決方案。

第三章：學(xué)無(wú)止境

敏捷開發(fā)需要持續(xù)不斷的學(xué)習(xí)和充電（所有行業(yè)都是，好嗎?。。?/p>

5.跟蹤變化

你能嗅到將要流行的新技術(shù)，知道它們已經(jīng)發(fā)布或者投入使用。如果必須把工作切換到一種新的技術(shù)領(lǐng)域，你能做到。

平衡的藝術(shù)：

• 正確把握對(duì)新技術(shù)的投入精力
• 不可能精通每個(gè)技術(shù)，只要在某些方面成為專家，用同樣的方法，很容易成為新領(lǐng)域的專家
• 要明白為什么需要這項(xiàng)新技術(shù)，它企圖解決什么樣的問題？可以被用在什么地方？
• 避免一時(shí)沖動(dòng)情況下，只是想把新技術(shù)引入開發(fā)中，在做決策前，需要評(píng)估新技術(shù)的優(yōu)勢(shì)，開發(fā)一個(gè)小的原型系統(tǒng)

6.對(duì)團(tuán)隊(duì)投資

提供個(gè)人和團(tuán)隊(duì)學(xué)習(xí)的更好平臺(tái)，例如通過午餐會(huì)議增進(jìn)每個(gè)人的知識(shí)和技能，并且?guī)椭蠹揖奂谝黄疬M(jìn)行溝通交流。

平衡的藝術(shù)：

• 一起讀書，但是選好的書
• 盡量讓講座走入團(tuán)隊(duì)，如果午餐會(huì)議在禮堂中進(jìn)行，還要使用幻燈片，那么減少了接觸和討論機(jī)會(huì)
• 堅(jiān)持有規(guī)律講座，持續(xù)、小步前進(jìn)才是敏捷
• 如果有人因?yàn)槌燥埲毕?，用美食誘惑他們
• 不要局限于純技術(shù)主題，項(xiàng)目估算、溝通技巧非技術(shù)主題也可以

7.懂的丟棄

新技術(shù)會(huì)讓人感到恐懼，畢竟需要學(xué)習(xí)很多東西。但是已有的技能和習(xí)慣為你打好了基礎(chǔ)，但不能依賴它們。

8.打破砂鍋問到底

不停地問為什么，不能只滿足別人告訴你的表面現(xiàn)象，要不停地提問知道你明白問題的根源。

9.把握開發(fā)節(jié)奏

項(xiàng)目開發(fā)需要一致和穩(wěn)定的節(jié)奏。編輯，運(yùn)行測(cè)試，代碼復(fù)審，一致的迭代，然后發(fā)布。如果知道什么時(shí)候開始下一個(gè)節(jié)拍，跳舞就會(huì)更加容易

平衡的藝術(shù)：

• 在每天結(jié)束的時(shí)候，測(cè)試代碼，提交代碼，沒有殘留的代碼
• 不要搞得經(jīng)常加班
• 以固定、規(guī)律的長(zhǎng)度運(yùn)行迭代
• 如果開發(fā)過于密集，你就會(huì)筋疲力盡
• 有規(guī)律的開發(fā)節(jié)奏會(huì)暴露很多問題，讓你有更多鼓起勇氣的借口
• 就像減肥一樣，一點(diǎn)點(diǎn)的成功也是很大的鼓勵(lì)，小而可達(dá)到的目標(biāo)會(huì)讓每個(gè)人全速前進(jìn)，慶祝每一次難忘的成功：共享沒事和啤酒或者團(tuán)隊(duì)聚餐（我喜歡！?。。。?/li>

第四章：支付用戶想要的軟件

開發(fā)的目標(biāo)應(yīng)該由客戶決定，因此為了讓軟件符合用戶需求，要提早集成，頻繁集成，使得代碼一直保持可以發(fā)布，由于需要一次又一次給用戶演示，因此應(yīng)當(dāng)提早實(shí)現(xiàn)自動(dòng)化部署。

10.讓客戶做決定

開發(fā)者、經(jīng)理或者業(yè)務(wù)分析師不應(yīng)該做業(yè)務(wù)方面的決定。用業(yè)務(wù)負(fù)責(zé)人能夠理解的語(yǔ)言，向他們?cè)敿?xì)解釋遇到的問題，并讓他們做決定。

平衡的藝術(shù)：

• 記錄客戶做的決定，并注明原因
• 不要用低級(jí)別和沒價(jià)值的問題打擾繁忙的業(yè)務(wù)人員
• 不要隨意假設(shè)低級(jí)別的問題不會(huì)影響他們的業(yè)務(wù)
• 如果業(yè)務(wù)負(fù)責(zé)人回答“我不知道”，這也是一個(gè)稱心如意的答案，也許是他們還沒想那么遠(yuǎn)，也許是他們只有看到運(yùn)行的實(shí)物才能評(píng)估結(jié)果，盡可能給他們提供建議，實(shí)現(xiàn)代碼的時(shí)候也要考慮可能出現(xiàn)的變化

11.讓設(shè)計(jì)指導(dǎo)而不是操作開發(fā)

好的設(shè)計(jì)應(yīng)該是正確的，而不是精確的。也就是說(shuō)，它描述的一切必須是正確的，不應(yīng)該涉及不確定或者可能會(huì)發(fā)生變化的細(xì)節(jié)，因此它是目標(biāo)，而不是具體處方。

如果寫得太具體有兩個(gè)弊端，一是程序員沒有代碼決定權(quán)，只是翻譯偽代碼，沒成就感；二是，花費(fèi)太多時(shí)間，如果項(xiàng)目變動(dòng)，或者規(guī)劃有問題，就浪費(fèi)了大量時(shí)間。

平衡的藝術(shù)：

• 在真正代碼驗(yàn)證之前，不要陷入太多的設(shè)計(jì)任務(wù)。當(dāng)對(duì)設(shè)計(jì)一無(wú)所知的時(shí)候，投入編碼也是一件危險(xiǎn)的事情
• 白板、草圖、便利貼都是非常好的設(shè)計(jì)工具，復(fù)雜的建模工具只會(huì)讓你分散精力，而不是啟發(fā)你的工作

12.合理地使用技術(shù)

根據(jù)需要選擇技術(shù)，首先決定什么是你需要的，接著為這些具體的問題評(píng)估使用技術(shù)，對(duì)任何要使用的技術(shù)，多問一些挑剔的問題，并真實(shí)地回答。

平衡的藝術(shù)：

• 如果沒有足夠經(jīng)驗(yàn)，不要急于決定用什么技術(shù)，如果再做系統(tǒng)原型，演示給用戶看時(shí)，可以用散列表代替數(shù)據(jù)庫(kù)
• 每一門技術(shù)都有優(yōu)缺點(diǎn)，需要清楚它的利弊
• 不要開發(fā)那些容易下載到的東西

13.保持可以發(fā)布

任何時(shí)候進(jìn)行項(xiàng)目展示時(shí)，都能很自信毫不猶豫地給別人演示最新構(gòu)建的軟件。項(xiàng)目一直處于可以運(yùn)行的穩(wěn)定狀態(tài)。

平衡的藝術(shù)：

• 做了一些大改動(dòng)，需要一個(gè)月才能保證發(fā)布，這種情況應(yīng)該只是例外，不能養(yǎng)成習(xí)慣
• 如果不得不讓系統(tǒng)長(zhǎng)期不可以發(fā)布，那么做一個(gè)分支版本

14.提早集成，頻繁集成

代碼集成是主要的風(fēng)險(xiǎn)來(lái)源，要想規(guī)避這個(gè)風(fēng)險(xiǎn)，只有提早集成，持續(xù)有規(guī)律地進(jìn)行集成。

平衡的藝術(shù)：

• 成功的集成就意味著所有的單元測(cè)試不停地通過
• 通常每天都要和團(tuán)隊(duì)其他的成員一起集成代碼好幾次。但是如果每次修改就集成，大部分時(shí)間花在集成而不是寫代碼，那么就是集成得太過頻繁了
• 如果不夠頻繁，也許發(fā)現(xiàn)每天都在解決代碼集成帶來(lái)的問題，而不是專心寫代碼

15.提早實(shí)現(xiàn)自動(dòng)化部署

一開始就實(shí)現(xiàn)自動(dòng)化部署應(yīng)用，使用部署系統(tǒng)安裝你的應(yīng)用，保證在不同的機(jī)器上用不同的配置文件測(cè)試依賴的問題。系統(tǒng)的安裝或者部署應(yīng)該簡(jiǎn)單、可靠及可重復(fù)。

16.使用演示獲得頻繁反饋

清晰可見的開發(fā)，在開發(fā)的時(shí)候保持應(yīng)用可見（客戶心中也要了解）。每隔一周或者兩周，邀請(qǐng)所有客戶，演示最新完成的功能，積極獲得他們的反饋

17.使用短迭代，增量發(fā)布

短迭代讓人感覺非常專注且具有效率。你能看到一個(gè)實(shí)際確切的目標(biāo)。嚴(yán)格的最終期限迫使你做出一些艱難的決策，沒有遺留下長(zhǎng)期懸而未決的問題。

平衡的藝術(shù)：

• 如果每個(gè)迭代周期不夠用，要么任務(wù)太大，要么迭代周期太短（所以一定要把握自己的節(jié)奏和時(shí)間）
• 如果發(fā)布功能背離用戶需求，多半是因?yàn)榈芷谔L(zhǎng)了
• 增量的發(fā)布時(shí)必須的，并且能為用戶提供價(jià)值

18.固定的價(jià)格意味著背叛承諾

基于真實(shí)工作的評(píng)估，讓團(tuán)隊(duì)和客戶一起，真正地在當(dāng)前項(xiàng)目中工作，做的具體實(shí)際的評(píng)估，由客戶控制他們要的功能和預(yù)算。

第五章：敏捷反饋

19.守護(hù)天使

使用自動(dòng)化的單元測(cè)試，好的單元測(cè)試能夠?yàn)槟愕拇a問題提供及時(shí)的警報(bào)。如果沒有到位的單元測(cè)試，不要進(jìn)行任何設(shè)計(jì)和代碼修改。

平衡的藝術(shù)：

• 人們不編寫單元測(cè)試的很多借口都是因?yàn)榇a中的設(shè)計(jì)缺陷。通?？棺h越強(qiáng)烈，就說(shuō)明設(shè)計(jì)越糟糕
• 不是測(cè)試越多質(zhì)量就越高，測(cè)試必須要有效，如果測(cè)試無(wú)法發(fā)現(xiàn)任何問題，也許他們就是沒有測(cè)試對(duì)路

20.先使用它再實(shí)現(xiàn)它

利用測(cè)試驅(qū)動(dòng)開發(fā)作為設(shè)計(jì)工具，這樣只有具體理由才開始編碼，可以專注于設(shè)計(jì)接口，而不會(huì)被很多實(shí)現(xiàn)細(xì)節(jié)干擾

21.不同環(huán)境，就有不同問題

使用持續(xù)集成工具，在每個(gè)支持的平臺(tái)和環(huán)境中運(yùn)行單元測(cè)試，要積極尋找問題，而不是等問題來(lái)找你

22.自動(dòng)驗(yàn)收測(cè)試

為核心業(yè)務(wù)邏輯創(chuàng)建測(cè)試，讓你的客戶單獨(dú)驗(yàn)證這些測(cè)試，要讓它們像一般測(cè)試一樣可以自動(dòng)運(yùn)行。

23.度量真實(shí)地進(jìn)度

使用代辦事項(xiàng)，使得下一步工作是可見的，有助于進(jìn)度度量，而不是按照百分比安排。不要用不恰當(dāng)?shù)亩攘縼?lái)欺騙自己或者團(tuán)隊(duì)，要評(píng)估那些需要完成的待辦事項(xiàng)。（每天列清單果然是好習(xí)慣，再加番茄工作法，用來(lái)計(jì)時(shí)）

平衡的藝術(shù)：

• 時(shí)間單元不要太細(xì)或者太粗，6分鐘或者一周都不合適（所以番茄工作法的半個(gè)小時(shí)，一個(gè)小時(shí)是OK的）
• 關(guān)注功能，而不是日程表
• 一周工作40個(gè)小時(shí)，實(shí)際上編碼時(shí)間不足40個(gè)小時(shí)，還有會(huì)議、電話等時(shí)間

24.傾聽用戶的聲音

每個(gè)用戶抱怨背后都隱藏了一個(gè)事實(shí)，找出真相，修復(fù)真正地問題。

平衡的藝術(shù)：

• 沒有愚蠢的用戶
• 只有愚蠢自大的開發(fā)用戶
• “它就是這樣的?！边@不是一個(gè)好答案
• 如果代碼問題解決不了，也許可以考慮通過修改文檔或者培訓(xùn)來(lái)彌補(bǔ)
• 用戶可能閱讀所有文檔，但是也可能不會(huì)

第六章：敏捷編碼

代碼要清晰表達(dá)意圖，項(xiàng)目是增量式開發(fā)，寫程序也應(yīng)該增量式編程。

25.代碼要清晰地表達(dá)意圖

要編寫清晰地而不是討巧的代碼，向代碼閱讀者明確表明你的意圖，可讀性差的代碼一點(diǎn)都不聰明（讓自己或者團(tuán)隊(duì)任何人，可以讀懂自己一年前寫的代碼，而且只讀一遍就知道它的運(yùn)行機(jī)制）

平衡的藝術(shù)：

• 現(xiàn)在對(duì)你顯而易見的事情，對(duì)別人可能并非如此
• 不要明日復(fù)明日，現(xiàn)在不做，以后你也不會(huì)做

26.代碼溝通

用注釋溝通，使用細(xì)心選擇的、有意義的命名。用注釋描述代碼意圖和約束。注釋不能替代優(yōu)秀的代碼

27.動(dòng)態(tài)評(píng)估取舍

動(dòng)態(tài)評(píng)估權(quán)衡，考慮性能、便利性、生產(chǎn)力、成本和上市時(shí)間。如果性能夠了，就應(yīng)該把注意力放在其他因素上，不要為了感覺上的性能提升或者設(shè)計(jì)的優(yōu)雅，從而將設(shè)計(jì)復(fù)雜化。

28.增量式編程

在很短的編輯/構(gòu)建/測(cè)試循環(huán)中編寫代碼，這要比花費(fèi)長(zhǎng)時(shí)間僅僅做編寫代碼的工作好得多，可以創(chuàng)建更加清晰、簡(jiǎn)單、易于維護(hù)的代碼。

平衡的藝術(shù)：

• 如果構(gòu)建和測(cè)試循環(huán)花費(fèi)的時(shí)間過長(zhǎng)，就不會(huì)希望經(jīng)常運(yùn)行它們。要保證測(cè)試可以快速運(yùn)行
• 在編譯和測(cè)試運(yùn)行中，停下來(lái)想一想，并暫時(shí)遠(yuǎn)離代碼細(xì)節(jié)，這是保證不會(huì)偏離正確方向的好辦法
• 要休息就好好休息。休息時(shí)遠(yuǎn)離鍵盤（哈哈哈）
• 要像重構(gòu)代碼一樣，重構(gòu)測(cè)試，而且要經(jīng)常重構(gòu)測(cè)試

29.保持簡(jiǎn)單

開發(fā)可以工作的、最簡(jiǎn)單的解決方案，除非有不可辯駁的原因，否則不要使用模式、原則和高難度技術(shù)之類的東西。

當(dāng)你覺得所編寫的代碼中沒有一行多余的，并且仍能交付全部功能時(shí)，這種感覺就對(duì)了。這樣的代碼容易理解和改正。

30.編寫內(nèi)聚的代碼

讓類的功能盡量集中，讓組件盡量小，要避免創(chuàng)建很大的類或組件，也不要?jiǎng)?chuàng)建無(wú)所不包的大雜燴類。

31.告知，不要詢問

不要搶別的對(duì)象或者組件的工作，告訴它做什么，然后盯著你自己的職責(zé)就好了。

32.根據(jù)契約進(jìn)行替換

通過替換遵循接口契約的類，來(lái)添加并改進(jìn)功能特性，要多使用委托而不是繼承。

平衡的藝術(shù)：

• 相對(duì)繼承來(lái)說(shuō)，委托更加靈活，適應(yīng)力更強(qiáng)
• 如果不確定一個(gè)接口做出來(lái)什么樣的承諾，或是有什么樣的需求，那就很難提供一個(gè)對(duì)其有意義的實(shí)現(xiàn)了

33.記錄問題解決日志

對(duì)解決的問題可以記錄以下條目：

• 問題發(fā)生日期
• 問題簡(jiǎn)述
• 解決方案詳細(xì)描述
• 引用文章或者網(wǎng)址
• 任何代碼片段，設(shè)置或?qū)υ捒蚪貓D

34.警告就是錯(cuò)誤

嵌入帶有警告的代碼，就跟嵌入有錯(cuò)誤或者沒有通過測(cè)試的代碼一樣，都是極差的做法。

35.對(duì)問題各個(gè)擊破

在解決問題時(shí)，要將問題域和周邊隔離開，特別是大型應(yīng)用中

36.報(bào)告所有的異常

處理或向上傳播所有的異常，不要講他們壓制不管，就算是臨時(shí)這樣做也不行，在寫代碼時(shí)要估計(jì)到會(huì)發(fā)生的問題。

37.提供有用的錯(cuò)誤信息

提供更易于查找錯(cuò)誤細(xì)節(jié)的方式，發(fā)生問題時(shí)，要展示出盡量多的支持細(xì)節(jié)，不過別人用戶陷入其中。

第八章：敏捷協(xié)作

38.定期安排會(huì)面時(shí)間

大家都期盼立會(huì)，希望彼此了解各自的進(jìn)度和手上的工作，而且不怕把各自遇到的問題拿出來(lái)公共討論。

39.架構(gòu)師必須寫代碼

積極的編程可以帶來(lái)深入的理解，不要使用不愿意編程的架構(gòu)師——不知道系統(tǒng)的真是情況，是無(wú)法展開設(shè)計(jì)的。

架構(gòu)、設(shè)計(jì)、編碼和測(cè)試，這些工作給人的感覺就像是同一個(gè)活動(dòng)——開發(fā)的不同方面。它們彼此之間應(yīng)該是不可分割的。

40.實(shí)行代碼集體所有制

讓開發(fā)人員輪換完成系統(tǒng)不同領(lǐng)域中不同模塊的不同任務(wù)。

平衡的藝術(shù)：

• 不要無(wú)意間喪失團(tuán)隊(duì)的專家技能，某些開發(fā)人員在某個(gè)領(lǐng)域中極其精通，就讓他駐留此領(lǐng)域當(dāng)專家
• 大型項(xiàng)目中，如果每個(gè)人都隨意改變?nèi)魏未a，一定會(huì)把項(xiàng)目弄得一團(tuán)糟
• 開發(fā)人員不必了解項(xiàng)目每一個(gè)部分的每個(gè)細(xì)節(jié)，但是不能因?yàn)橐幚砟硞€(gè)領(lǐng)域的代碼而感到驚恐
• 有些場(chǎng)合是不能采用代碼集體所有制
• 任何人可能出車禍，或者被挖，這樣就增加了喪失知識(shí)的風(fēng)險(xiǎn)

41.成為指導(dǎo)者

分享自己的知識(shí)很有趣，付出的同時(shí)便有收獲，還可以激勵(lì)別人獲得更好的成果，而且提升了整個(gè)團(tuán)隊(duì)的實(shí)力

42.允許大家自己想辦法

指給別人正確的方向，而不是直接提供解決方案

43.準(zhǔn)備好后再共享代碼

絕不要提交尚未完成的代碼，故意嵌入編譯未通過的或者沒有通過單元測(cè)試的代碼，對(duì)項(xiàng)目來(lái)說(shuō)，應(yīng)被視為玩忽職守的犯罪行為

44.做代碼復(fù)查

代碼復(fù)查隨著開發(fā)活動(dòng)持續(xù)進(jìn)行，而且每次針對(duì)的代碼量相對(duì)較少，復(fù)查活動(dòng)就像是項(xiàng)目正在進(jìn)行的一部分，而不是一種令人畏懼的事情

45.及時(shí)通報(bào)進(jìn)展與問題

發(fā)布進(jìn)展?fàn)顩r、新的想法和目前正在關(guān)注的主題，不要等著別人來(lái)問項(xiàng)目狀態(tài)如何

尾聲：走向敏捷

哈哈，感覺入手敏捷開發(fā)吧！