1 做事
“出了問題，第一重要的是確定元兇，找到那個人！一旦證實了是他的錯誤，就可以保證這樣的問題永遠也不會再發生了。”
指責不會修復bug，把矛頭對準問題的解決辦法，而不是人。這是真正有用處的正面效應。
也許你不相信，但確實有些人常常不把解決問題放在最高優先級上。也許你也沒有。先自我反省一下，當有問題出現時，“第一”反應究竟是什麼？
一個重大的錯誤應該被當作是一次學習而不是指責他人的機會。
團隊成員們在一起工作，應互相幫助，而不是互相指責。
如果你沒有犯過任何錯誤，就說明你可能沒有努力去工作。
2 欲訴則不達
“你不需要真正地理解那塊代碼，它只要能夠工作就可以了。哦，它需要一個小小的調整。只要在結果中再加上幾行代碼，它就可以工作了。幹吧！就把那幾行代碼加進去，它應該可以工作。”
拙劣的代碼工人會這樣不假思索地改完代碼，然後快速轉向下一個問題；而優秀的程序員會挖掘更深一層，盡力去理解爲什麼這裏需要加1，更重要的是，他會想明白會產生什麼其他影響。
千里之堤，潰於蟻穴，大災難是逐步演化而來的。一次又一次的快速修復，每一次都不探究問題的根源，久而久之就形成了一個危險的沼澤地，最終會吞噬整個項目的生命。
如果有一位團隊成員宣佈，有一塊代碼其他人都很難看懂，這就意味着任何人（包括原作者）都很難維護它。請讓它變得簡單些。
3 對事不對人
“當L先生在做一個新方案介紹時，下面有人會說‘這樣設計很蠢！都沒有考慮線程安全！’（這也暗示着L先生很蠢）。”
事實上，最適合並且最有效的表達方式應該是“謝謝，L先生。但是我想知道，如果兩個用戶同時登錄會發生什麼情況？”
盡力貢獻自己的好想法，如果你的想法沒有被採納也無需生氣；不要因爲只是想體現自己的想法而對擬定的好思路畫蛇添足。
4 排除萬難，奮勇前進
“老鼠們打算在貓的脖子上系一個鈴鐺，這樣貓巡邏靠近時，就能預先得到警報。每隻老鼠都點頭，認爲這是一個絕妙的想法。這時一個年老的老鼠站出來說道’那麼，誰願意挺身而出去系鈴鐺呢？’毫無疑問，沒有一隻老鼠站出來。當然，這個絕妙的計劃也就這樣泡湯了。”
有時，絕妙的計劃會因爲勇氣不足而最終失敗。儘管前方很危險，但你必須有勇氣向前衝鋒，做你認爲對的事情。
當你勇敢地站出來時，如果受到了缺乏背景知識的抉擇者的抵制，你需要用他們能夠聽懂的話語表達。“更清晰的代碼”是無法打動生意人的。節約資金、獲得更好的投資回報，避免訴訟以及增加用戶利益，會讓論點更有說服力。
5 跟蹤變化
“軟件技術的變化如此之快，勢不可擋，這是它的本性。繼續用你熟悉的語言做你的老本行吧，你不可能跟上技術變化的腳步。”
如果只是掌握了工作中需要的技術並不夠。那樣的工作也許幾年之後就不再有了—它會被外包或者會過時，那麼你就將會出局。
迭代和增量式的學習；瞭解最新行情；參加本地的用戶組活動；參加研討會議；如飢似渴地閱讀。
6 對團隊投資
“不要和別人分享你的知識—自己留着。你是因爲這些知識才成爲團隊中的佼佼者，只要自己聰明就可以了，不用管其他失敗者。”
團隊中的開發者們各有不同的能力、經驗和技術。每個人都各有所長。不同才能和背景的人混在一起，是一個非常理想的學習環境。
一個學習型的團隊纔是較好的團隊。
每週，要求團隊中的一個人主持講座。他會給大家介紹一些概念，演示工具，或者做團隊感興趣的任何一件事。你可以挑一本書，給大家說說其中一些特別內容、項目或者實踐，無論什麼主題都可以。
7 懂得丟棄
“那就是你一貫的工作方法，並且是有原因的。這個方法也很好地爲你所用。開始你就掌握了這個方法，很明顯它是最好的方法。真的，從那以後就不要再改變了。”
打破舊習慣很難，更難的是自己還沒有意識到這個問題。丟棄的第一步，就是要意識到你還在使用過時的方法，這也是最難的部分。另一個難點就是要做到真正的丟棄舊習慣。 畢竟，汽車要比馬車車廂強多了。
不是完全忘記舊的習慣，而是隻在使用適當的技術時才使用它。
8 打破砂鍋問到底
“接受別人給你的解釋，別人告訴你問題出在了什麼地方，你就去看什麼地方。不需要再浪費時間去追根究底”
要不停的問“爲什麼”。不能只滿足於別人告訴你的表面現象，要不停的提問直到你明白問題的根源。
問“爲什麼”，但是要問到點子上。
當你問“爲什麼”的時候，也許你會被反問：“爲什麼你問這個問題？”。在提問之前，想好你提問的理由，這會有助於你問出恰當的問題。
9 把握開發節奏
“我們很長時間沒有進行代碼複審，所以這週會複審所有的代碼。”
在許多不成功的項目中，基本上都是隨意安排工作計劃，沒有任何規律。那麼樣的隨機安排很難處理。你根本不知道明天將會發生什麼。
但是，敏捷項目會有一個節奏和循環，讓開發變得更加輕鬆。Scrum約定了30天之內不應該發生需求變化，這樣可以確保團隊有一個良性的開發節奏。（Scrum是一種迭代式增量軟件開發過程，通常用於敏捷軟件開發。包括了一系列實踐和預定義角色的過程骨架。）
站立會議最好每天在固定的時間和地點舉行，比如說上午10點左右。要養成這樣的習慣，在那時就準備好一切參加站立會議。
10 讓客戶做決定
“開發者兼具創新和智慧，最瞭解應用程序。因此，所有關鍵決定都應該由開發者定奪。每次業務人員介入的時候，都會弄得一團糟，他們無法理解我們做事的邏輯。”
在設計方面，做決定的時候必須有開發者參與。可是，在一個項目中，他們不應該做所有的決定，特別是業務方面的決定。
記錄客戶做出的決定，並註明原因。好記性不如爛筆頭。
11 讓設計指導而不是操縱開發
“設計文檔應該儘可能詳細，這樣，低級的代碼工人只要敲入代碼就可以了。編寫代碼的時候，無論你發現什麼，絕不能偏離了設計文檔。”
設計滿足實現即可，不必過於詳細。
即使之前已經提交了設計文檔，也還會有一些意料之外的情況出現。時刻謹記，此階段提出的設計只是基於你目前對需求的理解而已。一旦開始了編碼，一切都會改變。設計及其代碼實現會不停地發展和變化。
設計可以分爲兩層：戰略和戰術。前期的設計屬於戰略，通常只有在沒有深入理解需求的時候需要這樣的設計。更確切的說，它應該只描述總體戰略，不應深入到具體的細節。
12 合理地使用技術
“你開始了一個新的項目，在你面前有一長串關於新技術和應用框架的列表。這些都是好東西，你真的需要使用列表中所有的技術。想一想，你的簡歷上將留下漂亮的一筆，用那些偉大的框架，你的新應用將具有極高的技術含量。”
這個技術框架真能解決這個問題麼？（如果需要，先做一個小的原型）
你將會被它拴住麼？（一些技術是賊船，一旦你使用了它，就會被它套牢，再也不可能回頭了。我們需要考慮它是開放技術還是專利技術）
維護成本是多少？（維護成本昂貴。我們聽說，有個項目的合同是支持一個規則引擎，引擎一年的維護費用是5萬美元，但是，這個數據庫只有30條規則）
不需開發你能下載到的東西。
新技術就應該像是新的工具，可以幫助你更好地工作，它自己不應該成爲你的工作。
13 保持可發佈
“我們剛試用的時候發現了一個問題，你需要立即修復它，放下你手頭的工作，去修復那個剛發現的問題。不用告訴其他任何人—趕快讓它工作就行了。”
已提交的代碼應該隨時可以行動。
在本地運行測試；檢出最新的代碼；提交代碼。
14 提早集成，頻繁集成
“只要沒有到開發的末尾階段，就不要過早地浪費時間去想如何集成你的代碼，至少也要等開發差不多的時候，纔可以考慮它。”
敏捷的一個主要特點就是持續開發，而不是三天打魚兩天曬網地工作。特別是在幾個人一起開發同一個功能時，更應該頻繁地集成代碼。
絕不要做大爆炸似的集成。
代碼集成是主要的風險來源。要想規避這個風險，只有提早集成，持續而有規律地進行集成。
15 提早實現自動化部署
“沒問題，可以手動安裝產品，尤其是給質量保證人員安裝。”
系統能在你的機器上運行，或者能在開發者和測試人員的機器上運行，當然很好，但是，它同時也需要能夠部署在用戶的機器上。
質量保證人員應該測試部署過程。
從第一天起就開始交付，一開始就實現自動化部署應用。
如果維護安裝腳本變得很困難，那很可能是一個早期警告，預示着—很高的維護成本。
16 使用演示獲得頻繁反饋
“客戶不停的更改需求，導致我們嚴重地延期。他們一次就應該想清楚所有想要的東西，然後把這些需求給我們。”
需求就像是流動着的油墨。你無法凍結需求，就像你無法凍結市場、競爭、知識、進化或者成長一樣。就算你真的凍結了，也很可能是凍結了錯的東西。
不一致的術語是導致需求誤解的一個主要原因。所以，需要維護一份項目術語表。人們應該可以公開訪問它，一般是在wiki或內部網裏。
項目啓動了一段時間以後，你就應該進入一種舒適的狀態，團隊和客戶建立了一種健康的富有創造性的關係。
17 使用短迭代，增量發佈
“我們爲後面的3年制定了漂亮的項目計劃，列出了所有的任務和可交付的時間表。只要我們那時候發佈了產品，就可以佔領市場”
給我一份詳細的長期報告，我就會給你一個註定完蛋的項目。
對於大項目，最理想的辦法就是小步前進，這也是敏捷方法的核心。大步跳躍大大地增加了風險，小步前進纔可以幫助你很好地把握平衡。
18 固定的價格就意味着背叛承諾
“對這個項目，我們必須要有固定的報價。雖然我們還不清楚項目的具體情況，但仍要有一個報價。”
固定價格的合同會是敏捷團隊的一大難題。我們一直在談論如何用持續、迭代和增量的方式工作。但是現在卻有些人跑過來，想提早知道它會花費多少時間及多少成本。
軟件項目天生就是變化無常的，不可重複。如果要提前給出一個固定的價格，就幾乎肯定不能遵守開發上的承諾。
如果你現在別無選擇，你不得不提供一個固定價格，那麼你需要學到真正好的評估技巧。
19 守護天使
“你不必爲單元測試花費那麼多時間和精力。它只會拖延項目的進度。好歹，你也是一個不錯的程序員—單元測試只會浪費時間。”
單元測試能及時提供反饋
單元測試讓你的代碼更加健壯
單元測試時有用的設計工具
單元測試是你自信的後臺
單元測試是可信的文檔
單元測試是學習工具
20 先用它再實現它
“前進，先完成所有的庫代碼。後面會有大量時間看用戶是如何思考的。現在只要把代碼扔過牆就可以了，我保證它沒有問題。”
很多成功的公司都是靠着“吃自己的狗食”活着。也就是說，如果要讓你的產品儘可能地好，自己先要積極地使用它。
編程之前，先寫測試。
先寫測試，你就會站在代碼用戶的角度來思考，而不僅僅是一個單純的實現者，這樣做是有很大區別的，你會發現因爲你自己要使用它們，所以能設計一個更有用、更一致的接口。
21 不同環境，就有不同問題
“只要代碼能在你的機器上運行就可以了，誰會去關心它是否可以在其他平臺上工作，你又不用其他平臺。”
一位同事的代碼失敗了，最終找到了罪魁禍首：一個.NET環境下的API在Windows XP和Windows2003上的行爲不同。平臺不同，造成了結果的不一樣。
使用持久集成工具，在每一種支持的平臺和環境中運行單元測試，要積極地尋找問題，而不是等問題來找你。
22 自動驗收測試
“很好，你現在用單元測試來驗證代碼是否完成了你期望的行爲。發給客戶吧。我們很快會知道這是否是用戶期望的功能。”
關鍵業務邏輯必須要獨立進行嚴格的測試，並且最後需要通過用戶的審批。但是，你又不可能拉着用戶，逐一模塊確認。所以你需要能自動比較用戶期望和實際完成的工作。
FIT（fit.c2.com），即集成測試框架，它很實用，可以更容易的使用HTML表格定義測試用例，並比較測試結果數據。
23 度量真正的進度
“用自己的時間表報告工作進度。我們會用它做項目計劃。不用管那些實際的工作時間，每週填滿40小時就可以了。”
時間表很難真實地反映工作完成狀況，因此它不可以用來進行計劃、評估或表現評估。
你曾經聽到開發人員報告一個任務完成了80%麼？然而過了一天又一天，一週又一週，那個任務仍然是完成80%。
隨意用一個比率進行度量是沒有意義的。所以不應該去計算工作量完成的百分比，而應該測定還剩下多少工作量沒有完成。如果你最初估計這個任務需要40個小時，在開發了35個小時之後，你認爲還需要另外30個小時的工作。那就得到了很重要的度量結果（這裏誠實非常重要，隱瞞真相毫無意義）
關注功能，而不是日程表。
24 傾聽用戶的聲音
“用戶就是會抱怨。這不是你的過錯，是用戶太愚蠢了，連使用手冊都看不懂。它不是一個bug，只是用戶不明白如何使用而已。他們本應該知道更多。”
不管它是否是產品的bug，還是文檔的bug，或者是對用戶社區理解的bug，它都是團隊的問題，而不是用戶的問題。
對於一些軟件，倒黴的用戶必須要配置那些包含了一些魔術數字的模糊系統文件，否則系統根本不會運行。系統既沒有錯誤提示消息，也不會崩潰，只是顯示大黑屏和一個斗大的“退出”按鈕。
每一個抱怨的背後都隱藏着一個事實。找出真相，修復真正的問題。
沒有愚蠢的用戶；只有愚蠢自大的開發人員。
“它就是這樣的。”這不是一個好答案。
你的用戶有可能會閱讀所有的文檔，記住其中的所有內容。但也可能不會。
25 代碼要清晰地表達意圖
“可以工作而且易於理解的代碼當然好，但是讓人覺得聰明更加重要。別人給你錢是因爲你腦子好使，讓我們看看你到底有多聰明。”
Hoare說“設計軟件有兩種方式。一種是設計得儘量簡單，並且明顯沒有缺陷。另一種方式是設計得儘量複雜，並且沒有明顯的缺陷。”
（Hoare創造了Algol 60編程語言，併發明瞭快速排序算法。於1980年獲得圖靈獎。）
代碼閱讀的次數要遠遠超過編寫的次數，所以在編寫的時候值得花點功夫讓它讀起來更加簡單。
當開發人員們像一羣旁觀者見到UFO一樣圍在代碼四周，感到恐懼、困惑與無助時，這個代碼的質量就可想而知了。
看一個例子：
coffeeShop.PlaceOrder(2);//通過閱讀代碼，可以大致明白這是要在咖啡店中下一個訂單。但是2代表什麼意思？
coffeeShop.PlaceOrder(2 /* large cup */); //不妨添加一些註釋。但註釋有時候是爲了幫寫得不好的代碼補漏。
public enum CoffeeCupSize
{
Small,
Medium,
Large
}
coffeeShop.PlaceOrder(CoffeeCupSize,Large);//如果使用上枚舉值，代碼就一目瞭然了。
應該讓自己或團隊的其他任何人，可以讀懂自己一年前寫的代碼，而且只讀一遍就知道它的運行機制。
26 用代碼溝通
“精確地解釋代碼做了什麼，每行代碼都要加註釋。不用管爲什麼要這樣編碼，只要告訴我們做了什麼就好了。”
源代碼可以讀懂，不是因爲其中的註釋，而應該是由於它本身優雅而清晰。
要儘量避免使用神祕的變量名。（i常用於循環索引變量，str常用於表示字符串。如果用str表示循環索引變量，可真不是好主意）
在代碼可以明確傳遞意圖的地方，不要使用註釋。
解釋代碼做了什麼的註釋用處不那麼大。相反，註釋要說明爲什麼會這樣寫代碼。
27 動態評估取捨
“性能、生產力、優雅、成本以及上市時間，在軟件開發過程中都是至關重要的因素。每一項都必須達到最理想的狀態。”
與其花費時間去提升千分之一的性能表現，也許減少開發投入，降低成本，並儘快讓應用程序上市銷售更有價值。
如果現在投入額外的資源和精力，是爲了將來可能得到的好處，要確認投入一定要得到回報。（大部分情況下，是不會有回報的）
28 增量式編程
“真正的程序員寫起代碼來，一干就是幾個小時，根本不停，甚至連頭都不擡。不要停下來去編譯你的代碼，只要一直往下寫就好了！”
如果不對自己編寫的代碼進行測試，保證沒有問題，就不要聯繫幾個小時，甚至連續幾分鐘進行編程。相反，應該採用增量式的編程方式。
採用增量式編程和測試，會傾向於創建更小的方法和更具內聚性的類。你應該經常評估代碼質量，並不時的進行許多小調整，而不是一次修改許多東西。
在寫了幾行代碼之後，你會迫切地希望進行一次構建/測試。在沒有得到反饋時，你不要走的太遠。
29 保持簡單
“通過編寫史上最複雜的程序，你將會得到美譽和認可，更不用提保住你的工作了。”
Andy曾經認識一個傢伙，他對設計模式非常着迷，想把它們全都用起來。有一次，要寫一個大概幾百行的代碼程序。在被別人發現之前，他已經成功將17種設計模式，都運用到那可憐的程序中了。—這不應該是編寫敏捷代碼的方式。
問題在於，許多開發人員傾向於將投入的努力與程序複雜性混同起來。如果你看到別人給出的解決方案，並評價說“非常簡單且易於理解”，很有可能你會讓設計者不高興。許多開發人員以自己程序的複雜性爲榮，如果能聽到“Wow，這很難，一定是花了很多時間和精力才做出來的吧。” 這時，他們就會面帶自豪的微笑了。其實應當恰恰相反，開發人員更應該爲自己能夠創建出一個簡單並且可用的設計而驕傲。
簡單不是簡陋。
30 編寫內聚的代碼
“你要編寫一些新的代碼，看看IDE中現在打開的是哪個類，就直接加進去吧。如果所有的代碼都在一個類或組件裏面，要找起來是很方便的。”
內聚性用來評估一個組建（包、模塊或配件）中成員的功能相關性。內聚程度高，表明各個成員共同完成了一個功能特性或是一組功能特性。內聚程度低的話，表明各個成員提供的功能是互不相干的。
類也要遵循內聚性。如果一個類的方法和屬性共同完成了一個功能，這個類就是內聚的。
不過，不要把一些東西分成很多微小的部分，而使其失去了實用價值。當你需要一隻襪子的時候，一盒棉線不能帶給你任何幫助。
31 告知，不要詢問
“不要相信其他的對象。從別人那裏去拿你需要的信息，然後自己處理，自己決策。不要放棄控制別人的機會”。
告知=命令，詢問=查詢
命令和查詢相分離模式，就是要將功能和方法分爲命令和查詢兩類，並在源碼中記錄下來，以做到將命令代碼都放在一起，並將所有查詢代碼都放在一起。
絕對不能允許一個看起來無辜的“查詢”去修改對象的狀態。
32 根據契約進行替換
“深層次的集成是很棒的。如果你需要其他類的函數，直接繼承它們就好了！”
保持系統靈活性的關鍵方式，是當新代碼取代原有代碼之後，其他已有的代碼不會意識到任何差別。
如果你不確定一個接口做出了什麼樣的承諾，或者有什麼樣的需求，那就很難提供一個對其有意義的實現了。
33 記錄問題解決日誌
“在開發過程中是不是經常遇到似曾相識的問題？這沒關係，以前解決過的問題，現在還是可以解決掉的。”
面對問題是開發人員的一種生活方式。當問題發生時，我們會希望記起第一次是如何解決的，而且希望下次能夠更快地把它搞定。但是，有時我們又記不清上次是如何修復的了。
不要在同一處跌倒兩次。
要想得到更好的效果，不妨維護一個保存曾遇到的問題以及對應解決方案的日誌，我們稱之爲每日日誌（daylog）。
可以選擇符合需求的任何格式，下面的內容可能用得上：
- 問題發生日期
- 問題簡述
- 解決方案詳細描述
- 引用文章或網址，以提供更多細節或相關信息
任何代碼片段、設置或對話框的截屏，只要它們是解決方案的一部分，或者可以幫助更深入地理解相關細節。
務必要將上述信息變爲計算機可搜索的格式。
34 警告就是錯誤
“編譯器的警告信息只不過是給過分小心和過於書呆子氣的人看的。它們只是警告而已。”
有些警告是過於挑剔的編譯器的良性副產品，但有些則不是。例如，一個關於未被使用的變量的警告，可能不會產生什麼惡劣影響，但卻有可能是暗示某些變量被錯誤使用了。
簽入帶有警告的代碼，就跟簽入有錯誤或者沒有通過測試的代碼一樣，都是極差的做法。
35 對問題各個擊破
“要調試一個明顯的錯誤，只要去查看整個系統的代碼，而且是要全部過一遍。畢竟你不知道問題可能發生在什麼地方，這樣做是找到它的唯一方式。”
單元測試帶來的積極效應是它會強迫形成代碼的分層。要保證代碼可測試，就必須把它從周邊代碼中解脫出來。
認識複雜問題的第一步，是將它們分離出來。
很多應用的代碼在編寫時沒有注意到這一點，使得分離變得特別困難。應用的各個構件部分之間會彼此糾結：想把這個部分單獨拿出來，其他的會緊隨而至。在這些狀況下，最好花一些時間把關注的代碼提取出來，而且創建一個可讓其工作的測試環境。
36 報告所有的異常
“不要讓程序的調試者看到那些奇怪的異常。處理它們是你的責任。把你調用的一切都包起來，然後發送自己定義的異常。”
作者曾經使用一個非常流行的開源程序庫時倍受打擊。作者調用的一個方法本來應該創建一個對象，可得到的卻是null，調查很久都沒有頭緒。幸好這個庫是開源的，所以他下載了源代碼，並找到了出問題的那個調用方法。那個方法認爲她的系統中缺少了某些必要的組件。這個底層方法拋出了帶有相關信息的異常。但是，上層方法卻偷偷地用沒有異常處理代碼的空catch代碼塊，把異常給忽略掉了，然後拋出了一個null。後來，作者安裝了相應的組件，問題解決了。
37 提供有用的錯誤信息
“不要嚇着用戶，嚇程序員也不行，要提供給他們乾淨整潔的錯誤信息。”
在設計一個登陸頁面時，當用戶輸錯密碼時，我們提示哪個信息更好呢：“Unable to perform operation”、“Couldn’t login…”、還是“Error validating password”
錯誤信息有助於問題的解決。當問題發生時，可以詳細研究問題的細節描述和發生上下文。
38 定期安排會面時間
“會議安排得越多越好。實際上，我們要安排更多的會議。”
立會 （站着開的會議，Scrum最早引入並被極限編程所強調的一個實踐）是將團隊召集在一起，並讓每個人瞭解當下進展狀況的好辦法。顧名思義，參與者們不允許在立會中就坐，這可以保證會議快速進行。一個人坐下來之後，會由於感到舒適而讓會議持續更長的時間。
要保證立會議題不發散，每個人只能回答下述三個問題：
- 昨天的收穫是什麼
- 今天計劃要做哪些工作
- 面臨着哪些障礙
大家都期盼着立會，希望彼此瞭解各自的進度和手上的工作，而且不怕把各自遇到的問題拿出來公開討論。
39 架構師必須寫代碼
“我們的專家級架構師會提供設計好的架構，供你編寫代碼。他經驗豐富，拿的薪水很高，所以不要用一些愚蠢的問題或者實現上的難點來浪費他的時間。”
這些架構師通常在項目開始時介入，繪製各種各樣的設計圖，然後在重要的代碼實現開始之前離開。有太多這種“Powerpoint架構師”。由於得不到反饋，而且設計會隨着時間而演進，所以他們的架構設計工作也不會有很好的收效。
新系統的設計者必須要親自投入到實現中去。
40 實行代碼集體所有制
“不用擔心那些煩人的bug，Joe下週假期結束回來後會把它解決掉的。在此之前先想個權宜之計應付一下吧。”
不應像國家宣稱對領土的所有權一樣，聲明個人對代碼的所有權。任何一位團隊成員，重要理解某段代碼的來龍去脈，就應該可以對其進行處理。如果某一段代碼只有一位開發人員能夠處理，項目的風險無形中也就增加了。
相比找出誰的主意最好、誰的代碼實現最爛而言，解決問題，並讓應用滿足用戶的期望更爲重要。
在大型項目中，如果每個人都可以隨意改變任何代碼，一定會把項目弄得一團糟。代碼集體所有制並不意味着可以隨心所欲、到處破壞。
41 成爲指導者
“你花費了大量的時間和精力，才達到目前的水平。對別人要有所保留，這樣讓你看起來更有水平。讓隊友對你超羣的技能感到恐懼吧。”
教學相長。通過詳細解釋自己知道的東西，可以使自己的理解更深入。當別人提出問題時，也可以發現不同的角度。
成爲指導者，意味着要分享，而不是固守自己的經驗、知識和體會。
42 允許大家自己想辦法
“你這麼聰明，直接把乾淨利落的解決方案告訴團隊其他人就好了。不要浪費時間告訴他們爲什麼這麼做。”
作爲指導者，應該鼓勵、引領大家思考如何解決問題。
用問題來回答問題，可以引導提問的人走上正確的道路 。
43 準備好後再共享代碼
“別管是不是達到代碼簽入的要求，要儘可能頻繁的提交代碼，特別是要下班的時候。”
向代碼庫中提交仍在開發的代碼，會帶來很多風險。當其他開發者獲取最新版本的代碼時，也會受到這些代碼的影響。
絕不要提交尚未完成的代碼。故意簽入編譯未通過或是沒有通過單元測試的代碼，對項目來說，應被視作玩忽職守的犯罪行爲。
44 做代碼複查
“用戶是最好的測試人員。別擔心–如果哪裏出錯了，他們會告訴你們的。”
代碼剛剛完成時，是尋找問題的最佳時機。如果放任不管，它也不會變得更好。
管理層擔心進行代碼複查所耗費的時間。他們不希望團隊停止編碼，而去參加長時間的代碼複查會議。開發人員對代碼複查也感到擔心，允許別人看他們的代碼，會讓他們有受威脅的感覺。這影響了他們的自尊心。
要尋找深藏不露的代碼bug，正式地進行代碼檢查，其效果是任何已知形式測試的兩倍，而且是移除80%缺陷的唯一已知方法。
在極限編程中，不存在一個人獨立進行編碼的情況。編程總是成對進行的 ：一個人在鍵盤旁邊（擔任司機的角色），另一個人坐在後面擔任導航員。他們會不時變換角色。有第二雙眼睛在旁邊盯着，就像是在進行持續的代碼複查活動，也就不必安排單獨的特定複查時間了。
你也可以考慮使用諸如Similarity Analyzer或Jester這樣的代碼分析工具。
不進行思考、類似於橡皮圖章一樣的代碼複查沒有任何價值。
45 及時通報進展和問題
“管理層、項目團隊以及業務所有方，都仰仗你來完成任務。如果他們想知道進展狀況，會主動找你要的。還是埋頭繼續做事吧。”
如果等到截止時間才發佈壞消息，那麼經理或技術主管就會擔心你再次讓他們失望，並開始每天多次檢查你的工作進度。
及時通報進展和問題，有情況發生時，就不會讓別人感到突然，而且他們也很願意瞭解目前的進展和狀況。他們會知道何時應提供幫助，而且你也獲得了他們的信任 。