第1章 敏捷-高效軟件開發之道

第2章 態度決定一切
1.做事
指責不會修復bug。把矛頭對準問題的解決方法，而不是人。
2.欲速則不達
不要墜入快速的簡單修復之中。要投入時間和精力保持代碼的整潔、敞亮。
3.對事不對人
設定最終期限；逆向思維；設立仲裁人；支持已經做出的決定。
4.排除萬難，奮勇前進
做正確的事。要誠實，要有勇氣去說出實情。

第3章 學無止境
5.跟蹤變化
跟蹤技術變化。你不需要精通所有技術，但需要清除知道行業的動向，從而規劃你的項目和職業生涯。
叠代和增量式的學習；了解最新行情；參加本地的用戶組活動；參加研討會議；如饑似渴地閱讀。
6.對團隊投資
提供你和團隊學習的更好平臺。通過午餐會議可以增進每個人的知識和技能，並幫助大家聚集在一起進行溝通交流。喚起人們對技術和技巧的激情，將會對項目大有裨益。
7.懂得丟棄
學習新的東西，丟棄舊的東西。在學習一門新技術的時候，要丟棄會阻止你前進的舊習慣。
8.打破砂鍋問到底
不停地問為什麽。不能只滿足於別人告訴你的表明現象。要不停地提問直到你明白問題的根源。
9.把握開發節奏
解決任務，在事情變得一團糟之前。保持事件之間穩定重復的間隔，更容易解決常見的重復任務。

第4章 交付用戶想要的軟件
10.讓客戶做決定
讓你的客戶做決定。開發者、經理或者業務分析師不應該做業務方面的決定。
11.讓設計指導而不是操作開發
好設計是一張地圖，它也會進化。設計指引你向正確的方向前進，它不是殖民地，它不應該標識具體的路線。你不要被設計操縱。
12.合理地使用技術
根據需要選擇技術。首先決定什麽是你需要的，接著為這些具體的問題評估使用技術。對任何要使用的技術，多問一些挑剔的問題，並真實地作出回答。
13.保持可以發布
保持你的項目時刻可以發布。保證你的系統隨時可以編譯、運行、測試並立即部署。
14.提早集成，頻繁集成
提早集成，頻繁集成。代碼集成是主要的風險來源。要想規避這個風險，只有提早集成，持續而有規律地進行集成。
15.提早實現自動化部署
一開始就實現自動化部署應用。使用部署系統安裝你的應用，在不同的機器上用不同的配置文件測試依賴問題。
16.使用演示獲得頻繁反饋
清晰可見的開發。在開發的時候，要保持應用可見。每隔一周或者兩周，邀請所有的客戶，給他們演示最新完成的功能，積極獲得他們的反饋。
17.使用短叠代，增量發布
增量開發。發布帶有最小卻可用功能塊的產品。每個增量開發中，使用1~4周左右叠代周期。
18.固定的價格就意味著背叛承諾
基於真實工作的評估。讓團隊和客戶一起，真正地在當前項目中工作，做具體實際的評估。由客戶控制他們要的功能和預算。

第5章 敏捷反饋
19.守護天使
使用自動化的單元測試。好的單元測試能夠為你的代碼問題提供及時的警報。如果沒有到位的單元測試，不要進行任何設計和代碼修改。
20.先用它再實現它
先用它再實現它。將TDD（測試驅動開發）作為設計工具，它會為你帶來簡單更有實效的設計。
21.不同環境，就有不同問題
不同環境，就有不同問題。使用持續集成工具，在每一種支持的平臺和環境中運行單元測試。要積極地尋找問題，而不是等問題來找你。
22.自動驗收測試
為核心的業務邏輯創建測試。讓你的客戶單獨驗證這些測試要讓他們像一般的測試一樣可以自動運行。
23.度量真實的進度
度量剩下的工作量。不要用不恰當的度量來欺騙自己或者團隊。要評估那些需要完成的待辦事項。
24.傾聽用戶的聲音
每一個抱怨的背後都隱藏了一個事實。找出真相，修復真正的問題。

第6章 敏捷編碼
25.代碼要清晰地表達意圖
要編寫清晰的而不是討巧的代碼。向代碼閱讀者明確表明你的意圖，可讀性差的代碼一點都不聰明。
26.用代碼溝通
用註釋溝通。使用細心選擇的、有意義的命名。用註釋描述代碼意圖和約束。註釋不能替代優秀的代碼。
27.動態評估取舍
動態評估權衡。考慮性能、便利性、生產力、成本和上市時間。如果性能表現足夠了，就將註意力放在其他因素上。不要為了感覺上的性能提升或者設計的優雅，而將設計復雜化。
28.增量式編程
在很短的編輯/構建/測試循環中編寫代碼。這要比花費長時間僅僅做編寫代碼的工作好的多。可以創建根據清晰、簡單、易於維護的代碼。
29.保持簡單
開發可以工作的、最簡單的解決方案。除非有不可辯駁的原因，否則不要使用模式、原則和高難度技術之類的東西。
30.編寫內聚的代碼
讓類的功能盡量集中，讓組件盡量小。要避免創建很大的類或組件，也不要創建無所不包的大雜燴類。
31.告知，不要詢問
告知，不要詢問。不要搶別的對象或是組件的工作。告訴它做什麽，然後盯著你自己的職責就好。
32.根據契約進行替換
通過替換代碼來擴展系統。通過替換遵循接口契約的類，來增加並改進功能特性。要多使用委托而不是繼承。

第7章 敏捷調試
33.記錄問題解決日誌
維護一個問題及其解決方案的日誌。保留解決方案是修復問題過程的一部分，以後發生相同或類似問題時，就可以很快找到並使用了。
34.警告就是錯誤
將警告視為錯誤。簽入帶有警告的代碼，就跟簽入有錯誤或者沒有通過測試的代碼一樣，都是極差的做法。簽入構建工具中的代碼不應該產生任何警告信息。
35.對問題各個擊破
對問題各個擊破。在解決問題時，要將問題域與其周邊隔離開，特別是在大型應用中。
36.報告所有的異常
處理或是向上傳播所有的異常。不要講它們壓制不管，就算是臨時這樣做也不行。在寫代碼時要估計到會發生的問題。
37.提供有用的錯誤信息
展示有用的錯誤信息。提供更易於查找錯誤細節的方式。發生問題時，要展示出盡量多的支持細節，不過別讓用戶陷入其中。

第8章 敏捷協作
38.定期安排會面時間
使用立會。立會可以讓團隊達成共。保證會議短小精悍不跑題。
立會：必須站著，不能坐著，否則會影響會議時間，因為大部分不喜歡站著進行長時間的談話。
立會議題：昨天有什麽收獲；今天計劃要做哪些工作；面臨著哪些障礙。
39.架構師必須寫代碼
優秀的設計從積極的程序員那裏開始演化。積極的編程可以帶來深入的理解。不要使用不願意編碼的架構師-不知道系統的真實情況，是無法展開設計的。
40.實行代碼集體所有制
要強調代碼的集體所有制。讓開發人員輪換完成系統不同領域中不同模塊的不同任務。
41.成為指導者
要強調代碼的集體所有制。讓開發人員輪換完成系統不同領域中不同模塊的不同任務。
42.允許大家自己想辦法
給別人解決問題的機會。指給他們正確的方向，而不是直接提供解決方案。每個人都能從中學到不少東西。
43.準備好後再共享代碼
準備好後再共享代碼。絕不要提交尚未完成的代碼。故意嵌入編譯未通過或者沒有通過單元測試的代碼，對項目來說，應被視作玩忽職守的犯罪行為。
44.做代碼復查
復查所有的代碼。對於提升代碼質量和降低錯誤率來說，代碼復查是無價之寶。如果以正確的方式進行，復查可以產生非常實用而高效的成果。要讓不同的開發人員在每個任務完成後復查代碼。
45.及時通報進展與問題
及時通報進展與問題。發布進展狀況、新的想法和目前正在關註的主題。不要等著別人來問項目狀態如何。

第10章 尾聲：走向敏捷

<高效程序員的45個習慣：敏捷開發修煉之道>