學習筆記之《高效程式員的45個習慣》

有本關于靈活開發方面的書非常不錯《高效程式員的45個習慣-靈活開發修煉之道》，Venkat Subramaniam和Andy Hunt著，該書簡短、易讀、精煉、深入，深刻且實用。對于想要采用靈活方法的人很有價值。此書通過常理和經驗，闡述了為什麼應該在項目中實用靈活方法。更難得的是，這些行之有效的實戰經驗，竟然從一本書中得到了。如果能拿這些習慣在項目中一以貫之，肯定會受益匪淺。下本羅列該書這45個習慣，一并列出其中的Key Point.

--------------------------------------------------------------------------------------------

>>> 态度決定一切 <<<

【習慣01】做事

• 問題出來了，重點放在解決問題上，而不是在指責犯錯者上糾纏。
• 動機要明确，重點是做事，不是為了自己的面子，也不是為了指責，也無意個人智力決鬥。 
• 過程符合标準并不意味着結果是正确的。靈活團隊重結果勝于重過程。 
• 指責不會修改bug.把矛頭對準解決問題的辦法，而不是人。這是真正有用處的正面效應。
• 一個重大的錯誤應該被當是一次學習而不是指責他人的機會。團隊應該互幫互助，而不是指責。

【習慣02】欲速則不達

• 千裡之堤毀于蟻穴，大災難是逐漸演化來的。一次又一次快速修複每一次都不探究問題的根源，久而久之就形成了一個危險的沼澤地，最終會吞噬整個項目的生命。
• 在工作壓力下，不去深入了解真正的問題以及可能的後果，就快速修改代碼，這樣隻能解決表面問題，最終會引發大問題。
• 重構代碼之前必須徹底了解它，否則就不能進行有效的改變！ 
• 實行代碼複審，不僅有助于代碼更好了解，而且是發現bug最有效的方法之一。
• 不要墜入快速的簡單修複之中。要投入時間和精力來保持代碼的整潔、敞亮。

【習慣03】對事不對人

• 面對一個明顯的錯誤最好的反應:詢問你的隊友并提出你的顧慮。--沒有譴責，沒有評判，隻是簡單的表達自己的觀點。整個團隊要關注真正有價值的問題，而不是勾心鬥角，誤入歧途。
• 好的軟體産品和好的軟體設計，都需要大量的創造力和洞察力。分享并融合各種不同的想法和觀點，遠遠勝于單個想法為項目。帶來的價值。負面的評論和态度會扼殺創新。 
• 把問題重點放在解決問題上，而不是去極力證明誰的主意更好。  
• 經常提出自己的觀點和建議，記住，任何一個專家都是這麼開始的。你不需要很出色才起步，但必須起步才能變得很出色
• 讓我們驕傲的應該是解決了問題，而不是比較出誰的主意更好。

【習慣04】排除萬難，奮勇前進

• 有時，絕妙的計劃會因為勇氣不足而最終失敗。盡管前方很危險，你必須有勇氣向前沖鋒，做你認為對的事情。
• 踐行良好的習慣。 
• 做正确的事。要誠實，要有勇氣去說出實情。有時,這樣做很困難，是以我們要有足夠勇氣。
• 有時候勇氣是掃除障礙的唯一途徑，否則問題會一直惡化下去。鼓起勇氣從克服恐懼開始。
• 如果沒有了解那段代碼，不要輕易地否定和重寫它們。那不是勇氣，而是魯莽。

--------------------------------------------------------------------------------------------

>>> 學無止境 <<<

【習慣05】跟蹤變化

• 唯有變化是永恒的
• 疊代和增量式的學習
• 了解最新的行情
• 參加本地的使用者組活動
• 參加研讨會議
• 如饑如渴地閱讀
• 不需要精通所有的技術，但需要清楚知道行業的動向，進而規劃你的項目和職業生涯。
• 你不可能精通每一項技術，也沒有必要這樣做。
• 隻要你在某些方面成為專家，就能使用同樣的方法，很容易成為新領域的專家。

【習慣06】對團隊投資

• 一個學習型的團隊才是較好的團隊
• 午餐會議是在團隊中分享知識非常好的方式。
• 總是要成為你所在的團隊中最差的一位。這樣才有動力超越他們。
• 堅持有計劃有規律地舉行講座。持續、小步前進才是靈活。稀少、間隔時間長的會議非靈活也。
• 通過午餐會議可以增進每個人的知識和技能，并能幫助大家聚集在一起進行溝通交流。 

【習慣07】懂得丢棄

• 靈活的根本之一就是擁抱變化。既然變化是永恒的，你有可能一直使用相同的技術和工具嗎?
• 相比而言，開發者的時間才是緊缺和昂貴的資源。
• 需要耗費10人年開發的J2EE項目已經從輝煌走向下坡路。PHP,Ruby on Rails這樣的架構越來越受到關注。
• 隻有更少被舊習慣牽絆，才容易養成新習慣。
• 學習新的東西，丢棄舊的東西。在學習一門新技術的時候，要丢棄會阻止你前進的舊習慣。
• 畢竟汽車要比馬車車廂強得多。 

【習慣08】打破砂鍋問到底

• 在了解一個問題的時候，需要漸次地問5個以上的為什麼。
• 不停地問為什麼。不能隻滿足于别人告訴你的表面現象。要不停地提問直到你明白問題的根源。
• 好比是從礦石中采掘貴重的珠寶。要不停的篩選無關的物質，一次比一次深入，直到找到發光的寶石。
• 你要能感覺到真正地了解了問題，而不是隻直到表面的症狀。
• 在提問之前，想好你提問的理由，這會有助于你問出恰當的問題。

【習慣09】把握開發節奏

• 要養成這樣的習慣，在那時就準備好一切參加站立會議。
• 不管你的一個疊代是多長，都應該堅持--確定每個疊代周期的時間相同很重要。
• 解決任務在事情變得一團糟之前。保持事件穩定重複的間隔，更容易解決常見的重複任務。
• 項目開發需要有一緻和穩定的節奏。如果知道什麼時候開始下一個節拍，跳舞就會更加容易。

--------------------------------------------------------------------------------------------

>>> 傳遞使用者想要的軟體 <<<

【習慣10】讓客戶做決定 

• 在設計方面，做決定的時候必須有開發者參與。
• 開發者能做的一個最重要的決定就是:判斷哪些是自己決定不了的，應該讓企業主做決定。
• 讓你的客戶做決定。開發者、經理或者業務分析師不應該做業務方面的決定。
• 用業務負責人能夠了解的語言，向他們詳細解釋遇到的問題，并讓他們做決定。
• 業務應用需要開發者和業務負責人互相配合來開發。

【習慣11】讓設計指導而不是操縱開發

• 設計是軟體開發過程不可缺少的步驟。
• 設計滿足實作即可，不必過于詳細。
• 做到精确，如果你自己都不清楚所談論的東西，就根本不可能精确地描述它。
• 戰略級别的設計不應該具體說明程式方法、參數、字段和對象互動精确順序的細節。那是戰術設計的任務。
• 不要一開始就進行戰術設計，它的重點是集中在單個的方法或資料類型上。
• 這時，更适合讨論如何設計類的指責。因為這仍然是一個高層次、面向目标的設計。
• 好設計是一張地圖，它也會進化。設計指引你向正确的方向前進，它不是殖民地，它不應該辨別具體的路線。
• 你不要被設計操縱。
• 好的設計應該是正确的，而不是精确的。
• 計劃是沒有價值的，但計劃的過程是必不可少的。

【習慣12】合理地使用技術

• 盲目地為項目選擇技術架構，就好比是為了少交稅而生孩子。
• 代碼寫的越少，需要維護的東西就越少。
• 不要開發你能下載下傳到的東西。
• 要考慮:這個技術架構真能解決這個問題嗎? 你将會被它栓住嗎? 維護成本是多少。
• 根據需要選擇技術。首先決定什麼是你需要的，接着為這些具體的問題評估使用技術。
• 對任何要使用的技術，多問一些挑剔的問題，并真實地作出回答。

【習慣13】保持可以釋出

• 任何時候隻要你沒有準備好，那就是敵人進攻你的最佳時機。
• 已送出的代碼應該随時可以行動。
• 簡單流程。在本地進行測試->檢出最新的代碼->送出代碼.
• 最好的辦法，應該有一個持續內建系統，可以自動內建并報告內建結果。
• 保持你的項目時刻可以釋出。保證你的系統随時可以編譯、運作、測試并立即部署

【習慣14】提早內建，頻繁內建

• 靈活的一個主要特點就是持續開發。
• 你能一邊進行內建，一邊進行獨立開發。使用mock對象，編寫獨立的單元測試，而不需要立刻就內建和測試。
• 絕不需要做大瀑布式的內建
• 代碼內建是主要的風險來源。要想規避這個風險，隻有提早內建，持續而有規律地進行內建。
• 成功的內建就意味着所有的單元測試不停地通過。

【習慣15】提早實作自動化部署

• 品質保證人員應該測試部署過程。
• 如果現在還是手工幫助品質保證人員安裝應用，花一些時間，考慮如何将安裝過程自動化。
• 一開始就進行全面部署，而不是等項目的後期，這會有很多好處。
• 使用部署系統安裝你的應用，在不同的機器上用不同的配置檔案測試以來的關系。
• 品質保證人員要像測試應用一樣測試部署。

【習慣16】使用示範獲得頻繁回報

• 需求就像是流動着的油墨
• 應該定期地，每隔一段時間，比如說一個疊代，就與客戶會晤，并且示範你已經完成的功能特性。
• 要頻繁地獲得回報
• 清晰可見的開發。在開發的時候，要保持應用可見。
• 每隔一周或兩周，邀請所有的客戶，給他們示範最新完成的功能，積極獲得他們的回報。
• 示範是用來讓客戶提出回報的，有助于駕馭項目的方向。

【習慣17】使用短疊代，增量開發

• 統一過程和靈活方法都使用疊代和增量開發。
• 疊代開發是，在小而重複的周期裡完成各種開發任務:分析、設計、實作、測試和獲得回報，是以叫疊代。
• 給我一份詳細的長期計劃，我就會給你一個注定完蛋的項目。
• 對付大項目，最理想的辦法就是小步前進，這也是明捷方法的核心。
• 釋出帶有最小卻可用功能塊的産品。每個增量開發中，使用1`4周左右疊代周期。
• 短疊代讓人感覺非常專注且具效率。你能看到一個實際并且确切的目标。
• 嚴格的最終期限迫使你做出一些艱難的決策，沒有遺留下長期懸而未決的問題。

【習慣18】固定的價格就意味着背叛承諾

• 固定的價格就是保證要背叛承諾。
• 基于真實工作的評估。
• 讓團隊和客戶一起，真正地在目前項目中工作，做具體實際的評估。由客戶控制他們要的功能和預算。
• 如果你對答案不滿意，那麼看看你是否可以改變問題。
• 如果你現在别無選擇，你不得不提供一個固定的價格，那麼你需要學到真正好的評估技巧。

--------------------------------------------------------------------------------------------

>>> 靈活回報 <<<

【習慣19】守護天使

• 靈活就是管理變化的，而且，代碼可能是變化最頻繁的東西。
• 編寫能産生回報的代碼。
• 確定測試是可以重複的。
• 測試你的邊界條件。
• 不要放過任何一個失敗的測試。
• 使用自動化的測試。好的單元測試能夠為你的代碼問題提供及時的警報。
• 如果沒有到位的單元測試，不要進行任何設計和代碼修改。
• 單元測試時優質股，值得投資。
• 人們不編寫單元測試的很多借口是因為代碼中的設計缺陷。
• 單元測試隻有在達到一定測試覆寫率的時候，才能真正地發揮作用。

【習慣20】先用它再實作它

• 編碼之前，先寫測試。
• 先寫測試，你就會站在代碼使用者的角度去思考，而不僅僅是一個單純的實作者。
• 先寫測試有助于消除過度複雜的設計，讓你可以專注于真正需要完成的工作。
• 一些不必要的過于複雜的事情，測試優先會幫助我們，防止我們走偏。
• 好的設計并不意味着需要更多的類。
• TDD有機會讓你編寫之前，可以深思熟慮将如何用它。
• 這會迫使你去思考它的可用性和便利性，并讓你的設計更加注重實效。
• 将TDD作為設計工具，它會為你帶來更簡單更有實效的設計。
• 這種感覺就是，隻有在具體理由的時候才開始編碼。你可以專注于設計接口，而不會被很多實作的細節幹擾。 

【習慣21】不同環境，就有不同問題

• 在不同的操縱系統及作業系統的不同版本都進行測試
• 利用自動化會節省時間
• 不同環境，就有不同問題。使用持續內建工具，在每一種支援的平台和環境中運作單元測試。
• 軟體在很多平台上出現bug很可能隻是因為棧布局的差異、機器子大小端的不同所緻。
• 硬體比開發人員的時間便宜。但如果你有很多配置，要支援大量的平台，可以選擇哪些平台需要内部測試。

【習慣22】自動驗收測試

• 關鍵業務邏輯必須要獨立進行嚴格測試，并且最後需要通過使用者的審批。
• 應該讓使用者在不必學習編碼的情況下，根據自己的需要進行添加、更新和修改資料。
• FIT(內建測試架構)，它很實用，可以更容易地使用HTML表格定義測試用例，并比較測試結果資料。
• 使用FIT，客戶可以定義帶有新功能的使用樣本。
• 如果領域專家提供了業務的算法、運算或方程式，為他們實作一套可以獨立運作的測試。
• 為核心的業務邏輯建立測試。讓客戶單獨驗證這些測試，要讓它們像一般的測試一樣可以自動運作。

【習慣23】度量真實的進度

• 判斷工作進度最好是實際花費的時間而不是估計的時間。
• 專注于你的方向。
• 如果能一直讓下一步是可見的，會有助于進度度量。最好的做法就是使用代辦事項(backlog).
• 代辦事項就是等待完成的清單。
• 清楚項目的真實進度，是一項強大的技術。
• 度量剩下的工作量。不要用不恰當的度量來欺騙自己或者團隊。要評估那些需要完成的代辦事宜。

【習慣24】傾聽使用者的聲音

• 當出了錯誤，你要盡可能地提供詳細資訊。
• 黑屏和含義不明的“退出”按鈕是很不友好的行為。
• 不管是産品bug,還是文檔bug，或者使用者了解bug，那都是團隊行為，而不是使用者問題。
• 每一個抱怨的背後隐藏了一個事實。找出真相，修複真正的問題。
• 對客戶的愚蠢抱怨，即不要生氣，也不要輕視。
• 沒有愚蠢的使用者，隻有愚蠢，自大的開發人員。

--------------------------------------------------------------------------------------------

>>> 靈活編碼 <<<

【習慣25】代碼要清晰地表達意圖

• 設計軟體有兩種方式。一種是設計得盡量簡單，明顯沒有缺陷。另一種是設計複雜，沒有明顯的缺陷。
• 開發代碼時，應該更注重可讀性，而不是隻圖自己友善。
• 要編寫清晰的而不是讨巧的代碼。
• 向代碼閱讀者明确表明你的意圖。可讀性差的代碼一點都不聰明。
• 應該讓自己或團隊任何人，可以讀懂自己一年前寫的代碼，而且隻讀一遍就知道它的運作機制。

【習慣26】用代碼溝通

• 建立代碼文檔無外乎兩種方式:利用代碼本身；利用注釋來溝通代碼之外的問題。
• 變量名運用正确、空格使用得當、邏輯分離清晰，以及表達式非常簡潔。
• 如何命名很主要，使用精心挑選的名稱和清晰的執行路徑，代碼幾乎不需要注釋。
• 為代碼中的每個類或子產品添加一個短小的描述，說明其目的以及是否有任何特别需求。
• 用注釋溝通。使用細心選擇的、有意義的命名。用注釋描述代碼意圖和限制。注釋不能替代優秀的代碼。
• 注釋就好像是你的朋友，可以先閱讀注釋，然後快速浏覽代碼，進而完全了解它做了什麼，以及如何做。

【習慣27】動态評估取舍

• 沒有最佳解決方案
• 動态評估權衡。考慮性能、便利性、生産力、成本和上市時間。
• 如果性能表現足夠了，就将注意力放在其他因素上。
• 不要為了感覺上的性能提升或者設計上的優雅，而将設計複雜化。
• 即使不能面面俱到，你也應該覺得得到了最重要的東西-客戶認為有價值的特性。
• 過早的優化是萬惡之源。
• 真正的高性能系統，從一開始設計時就在向這個方向努力。

【習慣28】增量式程式設計

• 如果不對自己編寫的代碼進行測試，保證沒有問題，就不要連續幾個小時，甚至連續幾分鐘進行程式設計。
• 應該采用增量式的程式設計方式。增量式程式設計可以精煉并結構化你的代碼。
• 采用增量式程式設計和測試，會傾向于建立更小的方法和更具内聚性的類。
• 在編寫代碼時，要經常留心可以改進的微小部分。
• 在很短的編輯/建構/測試循環中編寫代碼。這要比花費長時間僅僅做編寫代碼的工作好得多。可以建立更加清晰、簡單、易于維護的代碼。
• 在寫了幾行代碼之後，你會迫切地希望進行一次建構/測試循環。在沒有得到回報時，你不想走得太遠。

【習慣29】保持簡單

• 簡單不是簡陋
• 優雅的代碼第一眼看上去，就知道它的用處，而且很簡潔。
• 開發可以工作的、最簡單的解決方案。
• 除非不可辯駁的原因，否則不要使用模式、原則和高難度技術之類的東西。
• 當你感覺代碼沒有一行是多餘的，并且仍能傳遞全部的功能，這種感覺就對了。這樣的代碼容易了解和改正。
• 要将目标牢記于心:簡單、可讀性高的代碼。強行讓代碼變得優雅與過早優化類似，同樣會産生惡劣的影響。

【習慣30】編寫内聚的代碼

• 類也要遵循内聚性。如果一個類的方法和屬性共同完成一個功能，這個類就是内聚的。
• 讓類的功能盡量集中，讓元件盡量小。要避免建立很大的類或元件，也不要建立無所不包的大雜燴類。
• 感覺類群組件的功能很集中:每個類或元件隻做一件事，而且做的很好。bug很容易跟蹤，代碼也容易修改，因為類群組件的責任都很清晰。
• 有可能會把一些東西拆成很多微小的部分，而使其失去了實用價值。
• 具有良好内聚性的代碼，可能會根據需求的變化，而成比例地進行變更。

【習慣31】告知，不要詢問

• 面向過程的代碼取得資訊，然後做出決策。面向對象的代碼讓别的對象去做事情。
• 作為代碼的調用者，開發人員絕對不應該基于被調用對象的狀态做出任何決策，更不能去改變改對象的狀态。這樣的邏輯應該是邏輯應該是被調用對象的責任，而不是你的。在該對象之外替它做決策，就違反了封裝的原則，而且為bug提供了滋生的土壤。
• 指令與查詢相分離模式。就是将功能和方法分為指令和查詢兩類，并在源碼中記錄下來。
• 告知，不要詢問。不要搶了别的對象或元件的工作。告訴它做什麼，然後盯着你自己的職責就好了。
• 絕對不允許以個看起來無辜的查詢去修改對象的狀态。

【習慣32】根據契約進行替換

• 針對is-a關系使用繼承；針對has-a或uses-a關系使用委托。
• 通過替換代碼來擴充系統。通過替換遵循接口契約的類，來添加并改進功能特性。要多使用委托而不是繼承。
• 相對于繼承來說，委托更加靈活，适應力也更強。 
• 繼承不是魔鬼，隻是長久以來被大家誤解了。
• 如果你不确定一個接口做出了什麼樣的承諾，或是有什麼樣的需求，那就很難提供一個對其有意義的實作了。

--------------------------------------------------------------------------------------------

>>> 靈活調試 <<<

【習慣33】記錄解決問題的日志

• 好的日志格式:問題發生日期|簡述|解決方案|引用文章或網址|代碼、設定或對話框的截屏。
• 要将日志儲存為可供計算機搜尋的格式，就可以進行關鍵字搜尋以快速查找細節。
• 維護一個問題及其解決方案的日志。保留解決方案是修複問題過程的一部分，以後發生相同或類似問題時，就可以很快找到并使用了。
• 記錄問題的時間不能超過在解決問題上花費的時間。
• 找到以前的解決方法非常關鍵。
• 如果通過搜尋web，發現沒人曾經遇到同樣的問題，也許搜尋的方式有問題。
• 要記錄團隊做出一個重要決策的原因。

【習慣34】警告就是錯誤

• 在Eclipse中将警告做為錯誤處理的設定:Windows->Preferences->Java->Compiler->Errors/Warnings.
• 将警告視為錯誤。簽入有警告的代碼，就跟簽入有錯誤或者沒通過測試的代碼一樣，都是極差的做法。
• 簽入建構工具中代碼不應該産生任何警告資訊。
• 由于編譯器的bug或第三方工具或代碼的原因，有些警告無法消除。
• 棄用的方法被棄用是有原因的。不要再使用它們了。至少，安排一個疊代來将它們安全地移除掉。

【習慣35】對問題各個擊破

• 如果代碼依賴其他子產品，就應該使用mock對象，來把它從其他子產品中分離開。這樣做不但讓代碼更加健壯，且在發生問題時，也更容易定位來源。
• 用原型進行分離。
• 對問題各個擊破。在解決問題時，要将問題域與其周邊隔離開，特别是在大型應用中。
• 面對必須要隔離的問題時，感覺就像在一個茶杯中尋找一根針，而不是大海撈針。
• 如果将代碼從其運作環境中分離後，問題消失不見了，這有助于隔離問題。
• 另一方面，如果将代碼從其運作環境中分離後，問題還在，這同樣有助于隔離問題。
• 在向問題發起攻擊之前，先查找你的問題解決日志。
• 以二分查找的方式來定位問題是很有用的。也就是說，将問題空間分為兩半，看看哪一半包含問題。再講包含問題的一半進行二分，并不斷重複這個過程。

【習慣36】報告所有的異常

• 捕捉到異常後，為了不看到編譯器的提示，就把異常忽略掉--這種做法是危險的。
• 處理或是向上傳播所有的異常。不要将它們壓制不管，就算是臨時這樣做也不行，在寫代碼時要估計到會發生的問題。
• 當出現問題時，心裡知道能夠得到抛出的異常。而且沒有空的異常處理方法。
• 決定由誰來負責處理異常是設計工作的一部分。
• 不是所有的問題都應該抛出異常。
• 報告的異常應該在代碼的上下文中有實際意義。
• 要傳播不能處理的異常。

【習慣37】提供有用的錯誤資訊

• 要區分錯誤類型。程式缺陷 | 環境問題 | 使用者錯誤
• 展示有用的錯誤資訊。提供更易于查找錯誤細節的方式。發生問題時，要展示出盡量多的支援細節，不過别讓使用者陷入其中。
• 錯誤資訊有助于問題的解決。當發生問題時，可以詳細研究問題的細節描述和發生上下文。
• 像“無法找到檔案”這樣的錯誤資訊，就其本身而言無助于問題的解決。“無法打開/project/file以供提取”這樣的資訊更加有效。
• 沒有必要等待抛出異常來發現問題。在代碼關鍵點使用斷言以保證一切正常。當斷言失敗時，要提供與異常同樣詳細的資訊。
• 在提供更多資訊的同時，注意保密。
• 提供給使用者的資訊可以包含一個主鍵，以便于在日志檔案或稽核記錄中定位相關内容。

--------------------------------------------------------------------------------------------

>>> 靈活協作 <<<

【習慣38】定期安排會面時間

• 隻有開發團隊可以參與scrum例會。
• 站立開發，回答三個問題: 昨天收獲 | 今天計劃 | 面臨問題
• 使用立會。立會可以讓團隊達成共識。保證會議短小精悍不跑題。
• 大家都盼着立會。希望彼此了解各自的進度和手上的工作，而且不怕把各自遇到的問題拿出來公開讨論。
• 會議會占用開發時間，是以要盡量保證投入的時間有較大的産出。時間10-15分鐘比較理想。
• 提前預定時間。
• 要注意報告的細節。會議中給出具體的進度，但不要陷入細節中。
• 迅速地開始可以保證會議短小。不要浪費時間等着會議開始。

【習慣39】架構師必須寫代碼

• 不可能在PowerPoint幻燈片中進行編碼。
• 新系統的設計者必須要親自投入到實作中去。
• 鼓勵程式員參與設計，程式員在拒絕設計的同時，也就放棄了思考。
• 優秀的設計從積極的程式員那裡開始演化。積極的程式設計可以帶來深入的了解。不要使用不願意編碼的架構師-不知道系統的真實情況，是無法展開設計的。
• 不要允許任何人單獨進行設計，特别是你自己。

【習慣40】實行代碼集體所有制

• 相比找出誰的主意更好、誰的代碼實作很爛而言，解決問題，并讓應用滿足使用者的期望更為重要。
• 有好幾雙眼睛盯着一段代碼，這樣可以提升代碼的整體品質，使其易于維護和了解，并降低出錯率。
• 要強調代碼的集體所有制。讓開發人員輪換完成系統不同子產品中的不同任務。
• 項目中的絕大部分的代碼都必須能輕松應對。
• 如果不向整個團隊分享知識，反而增加了喪失知識的風險。

【習慣41】成為指導者

• 教學相長-與團隊其他人一起共事是很好的學習機會。
• 通過詳細解釋自己知道的東西，可以使自己的了解更深入。
• 與别人共事，激勵他們變得更出色，同時可以提升團隊的整體實力。
• 我們要成為指導别人的人，而不是折磨别人的人。
• 成為指導者。分享自己的知識很有趣-付出的同時便有收獲。還可以激勵别人活得更多的成果，而且提升了整個團隊的實力。
• 如果一直在就同一個主題向不同的人反複闡述，不妨記錄筆記，此後就此問題發一篇文章，甚至是一本書。
• 成為指導者是向團隊進行投資的一種極佳的方式。
• 結對程式設計是一種進行高效指導的、很自然的環境。

【習慣42】允許大家自己想辦法

• 授人以魚，三餐之需；授人以漁，終生之用。
• 作為指導者，應該鼓勵、引領大家思考如何解決問題。
• 給别人解決問題的機會。指給他們正确的方向，而不是直接提供解決方案。每個人都能從中學到東西。
• 用問題來回答問題，可以引導提問的人走上正确的道路。
• 如果有人真的陷入膠着狀态，就不要折磨他麼了。告訴他們答案，再解釋為什麼是這樣。

【習慣43】準備好後再共享代碼

• 完成一項任務後，應該馬上ga代碼，不應該讓代碼在開發機器上多停留一分鐘。如果代碼不能被别人內建使用，那又有什麼用處呢？
• 通常情況下，送出的檔案應該與一個特定的任務或是一個bug的解決相關。
• 要保證在送出代碼之前，所有的單元測試都是可以通過的。使用持續內建是保證源代碼控制系統中代碼沒有問題的一種良好方式。
• 準備好後再共享代碼。絕不要送出尚未完成的代碼。故意簽入編譯未通過，或沒有通過單元測試的代碼，對項目來說，應被視為玩忽職守的犯罪行為。
• 仍然應該頻繁送出代碼。

【習慣44】做代碼複查

• 代碼剛完成時，是尋找問題的最佳時機。
• 要尋找深藏不露的程式bug,正式地進行代碼檢查，其效果是任何已知形式測試的兩倍，而且是移除80%缺陷的唯一已知方法。
• 複查所有代碼。對于提升代碼品質和降低錯誤率來說，代碼複查是無價之寶。
• 不進行思考，類似于橡皮章一樣的代碼複查沒有任何價值
• 代碼複查需積極評價代碼的設計和清晰程度，而不隻是考量變量名和代碼格式是否符合組織的标準。
• 如果不及時跟進讨論中給出的建議，代碼複查時沒有實際意義的。
• 要確定代碼複查人員得到每次複查活動的回報。

【習慣45】及時通報進展與問題

• 及時通報進展與問題。釋出進展狀況、新的想法和目前正在關注的主題。不要等别人來問項目狀态如何。
• 當經理或同僚來詢問工作進度、最新的設計或研究狀況時，不會感到頭疼。
• 每日立會可以讓每個人都能明确了解最新的進展和形勢。
• 别花費太多的時間在進展與問題通報上面，還是應該保證開發任務的順利完成。
• 經常擡頭看看四周，而不是隻埋頭于自己的工作。