高效程序員的45個習慣(敏捷開發修煉之道)/圖靈程序設計叢書
Bear在這裡買的
amazon的參考
-----------------------------------------------------------
作者：(美)蘇帕拉馬尼亞姆//亨特|譯者:錢安川//鄭柯
出版社：人民郵電
ISBN：9787115215536
出版日期：2010/01/01
頁數：186
人民幣：RMB 35 元
-----------------------------------------------------------
第1章 敏捷——高效軟體開發之道
第2頁
它要求團隊中的每一個人（包括與團隊合作的人）都具備職業精神，並積極地期望項目能夠獲得成功。它並不要求所有人都是有經驗的專業人員，但必須有專業的工作態度——每個人都希望盡最大可能做好自己的工作。
第3頁
開發需要持續不斷，切勿時斷時續。（Continuous development，not episodic）
持續注入能力(Inject energy)
第4頁
敏捷開發就是在一個高度協作的環境中，不斷地使用回饋進行自我調整和完善。
評注: 即重構和迭代。
評注: 你要知錯能改，在事實面前主動承認自己的所有錯誤，你要能自我反省，經常編碼實戰，加強團隊協作精神。
第2章 態度決定一切
1. 做事
把矛頭對準問題的解決辦法，而不是人，這是真正有用處的正面效應
第13頁
指責不會修復bug。
勇於承認自己不知道答案，這會讓人感覺放心。一個重大錯誤應該被當作是一次學習而不是指責他人的機會。
2. 欲速則不達
要投入時間和精力保持代碼的整潔、敞亮
第16頁
另一種防止代碼難懂的重要技術是單元測試。單元測試幫助你很自然地把代碼分層，分成很多可管理的小塊⋯⋯它們是一種可執行的文檔。
3. 對事不對人
讓我們驕傲的應該是解決了問題，而不是比較出誰的主意更好
第20頁
1. 設定最終期限。
2. 逆向思維
3. 設立仲裁人
4. 支持已經做出的決定
第21頁
一旦方案被確定了（不管是什麼樣的方案），每個團隊成員都必須通力合作，努力實現這個方案。
設計充滿了妥協（生活本身也是如此），成功屬於意識到這一點的團隊。
讓我們驕傲的應該是解決了問題，而不是比較出誰的主意更好。
評注: 脫離實際的反方觀點會使爭論變味。若對一個想法有成見，你很容易提出一堆不太可能發生或者不太實際的情形去批駁它。這時，請捫心自問：類似問題以前發生過嗎？是否經常發生？
4. 排除萬難，奮勇前進
要誠實有勇氣去說出實情，有時候這樣做很困難，所以我們需要有足夠的勇氣
第3章 學無止境
5. 跟蹤變化
不需要精通所有技術，但需要清楚知道行業的動向，從而規劃你的專案和職業生涯
6. 對團隊投資
通過午餐會議可以增進每個人的知識和技能，並幫助大家聚集在一起進行溝通交流。喚起人們對技術和技巧的激情，將會對專案大有裨益。
7. 懂得丟棄
在學習一門新技術的時候，要丟去會阻止你前進的舊習慣。畢竟，汽車要比馬車強得多。
P.35
電腦和CPU曾經非常昂貴，而現在它們就是日用品。現在，開發者的時間才是緊缺和昂貴的資源。
Once upon a time, that might have been an acceptable trade-off. But not now. Machines and CPU cycles used to be the expensive part; now they are commodity. Developer time is now the scarce—and expensive—resource.
8. 打破砂鍋問到底
不能只滿足與別人告訴你的表面現象。要不停地提問直到你明白問題的根源。
9. 把握開發節奏
保持時間之間穩定重複的間隔，更容易解決常見的重複任務
P.40
有人說，上帝發明了時間，就是為了防止所有事情同時發生。
Conversely, a lot of practices have to happen “all the time,” that is, throughout the life of the project. It has been said that time is nature’s way of keeping everything from happening all at once. Well, we need to take that one step further and keep a couple different rhythms going so that everything on an agile project doesn’t happen all at once or happen at random, unpredictable times.
第41頁
鯊魚必須不停地向前遊，否則就會死亡。在這方面，軟體專案就像鯊魚
最大的節拍就是迭代時間
解決任務，在事情變得一團糟之前。保持事件之間穩定重複的間隔，更容易解決常見的重複任務。
評注: 有時候我會因為一些"緊急"的事務而難於堅持這種節奏。其實回頭來看，許多"緊急"的事務並不重要，甚至並不"緊急"。要有一份定力，將保持節奏作為很高的原則來堅持，持之以恆才能真正進入適宜的節奏中。
第4章 交付用戶想要的軟體
10. 讓客戶做決定
開發者、經理或者業務分析師不應該做業務方面的決定。用業務負責人能夠理解的語言，向他們詳細解釋遇到的問題，並讓他們做決定。
第46頁
開發者能做的最重要的決定就是：判斷哪些是自己決定不了的，應該讓客戶做決定。
11. 讓設計指導而不是操縱開發
好設計是一張地圖，它也會進化。設計指引你向正確的方向前進，它不是殖民地，它不應該標識具體的路線。你不要被設計（或者設計師）操控。
評注: 軟體專案是一個進化的工程，如何完全依靠設計，就失去了其最寶貴的創造力，這與建築是不一樣的！
P.51
正如美國總統艾森豪所說: 計劃是沒有價值的，但計劃的過程是必不可少的。
在設計過程中學習是有價值的，但設計本身也許沒有太大的用處。
12. 合理地使用技術
首先決定什麼是你需要的，接著為這些具體的問題評估使用技術，對任何要使用的技術，多問一些挑剔的問題，並真實地作出回答。
新技術就應該像是新的工具，可以幫助你更好地工作，她自己不應該是成為你的工作。
第53頁
不要開發你能下載到的東西
你的代碼寫得越少，需要維護的東西越少
評注: 代碼的成功不在於其數量，而在於其品質。不在於其消耗了多少腦力，而在於其能產生多少新的生產力。這個感覺是需要歲月磨礪後才會有的感覺，很像腳上的老繭，只有走過長路後才能積澱下來。
13. 保持可以發布
保證你的系統隨時可以編譯、運行、測試並立即部署。
14. 提早集成，頻繁集成
代碼集成式主要的風險來源。要想規避這個風險，只有提早集成，持續而有規律地進行集成。
15. 提早實現自動化部署
使用部署系統安裝你的應用，在不同的機器上用不同的配置檔測試依賴問題。品質保證人員要像測試應用一樣測試部署。
16. 使用演示獲得頻繁反饋
在開發的時候，要保持應用可見（而且客戶心中也要瞭解）。每隔一周或者兩周，邀請所有客戶，給他們演示最新完成的功能，積極獲得他們的回饋。
17. 使用短迭代，增量發布
發佈帶有最小卻可用功能塊的產品。每個增量開發中，使用1~4周左右的迭代週期。
第69頁
給我一份詳細的長期計畫，我就會給你一個註定完蛋的項目
Larman指出，軟體發展不是精細的製造業，而是創新活動。規劃幾年後客戶才真正使用的專案註定是行不通的
對付大項目，最理想的方法就是小步前進，這也是敏捷方法的核心
評注:對於其他創新工作，或者說人生也是一種創新工作，上述觀點都適用。
18. 固定的價格就意味著背叛承諾
讓團隊和客戶一起，真正地在當前專案中工作，做具體實際的評估。由客戶控制他們要的功能和預算。
第5章 敏捷反饋
19. 守護天使
好的單元測試能夠為你的代碼問題提供及時的警報。如果沒有到位的單元測試，不要進行任何的設計和代碼修改。
20. 先用它再實現它
使用測試驅動開發作為設計工具，它會為你帶來更簡單更實效的設計。
21. 不同環境，就有不同問題
使用持續集成工具。在每一種支援的平臺和環境中運行單元測試。要積極地尋找問題，為不是等問題來找你。
22. 自動驗收測試
為核心的業務邏輯創建測試，讓你的客戶單獨驗證這些測試，要讓它們像一般的測試一樣可以自動運行。
23. 度量真實的進度
不要用不恰當的度量來欺騙自己或者團隊。要評估那些需要完成的待辦事項。
24. 傾聽用戶的聲音
每一個抱怨的背後都隱藏了一個事實，找出真相，修復真正的問題。
評注:要多方面地考慮“用戶的抱怨"，這是一筆財富而不是一份負擔，但往往處理不當，會成為一份負債。
第6章 敏捷編碼
25. 代碼要清晰地表達意圖
向代碼閱讀者明確表明你的意圖。可讀性差的代碼一點也不聰明。
26. 用代碼溝通
使用細心選擇的、有意義的命名。用注釋描述代碼意圖和約束。注釋不能替代優秀的代碼。
P.107~108
Bear: 注釋轉成文件的示意圖
27. 動態評估取捨
考慮性能、便利性、生產力、成本和上市時間。如果性能表現足夠了，就將注意力放在其他因素上。不要為了感覺上的性能提升或者設計的優雅，而將設計複雜化。
28. 增量式編程
在很短的編輯/構建/測試迴圈中編寫代碼，這要比花費長時間僅僅做編寫代碼的工作好得多。可以創建更加清晰、簡單、易於維護的代碼。
29. 保持簡單
除非有不可辯駁的原因，否則不要使用模式、原則和高難度技術之類的東西。
30. 編寫內聚的代碼
讓類的功能儘量集中，讓組件儘量小。要避免創建很大的類或組件，也不要創建無所不包的大雜燴類。
31. 告知，不要詢問
不要搶別的物件或者是元件的工作。告訴它做什麼，然後盯著你自己的指責就好了。
32. 根據契約進行替換
通過替換遵循介面契約的類，來添加並改進功能特性。要使用更多的委託而不是繼承。
第7章 敏捷調試
33. 記錄問題解決日誌
保留解決方案是修復問題過程的一部分，以後發生相同或類似問題時，就可以很快找到並使用了。
34. 警告就是錯誤
簽入帶有警告的代碼，就跟簽入有錯誤或者沒有通過測試的代碼一樣，都是極差的做法。簽入構建工具中的代碼不應該產生任何警告資訊。
35. 對問題各個擊破
在解決問題時，要將問題域與周邊隔離開。特別是在大型應用中。
36. 報告所有的異常
不要將它們壓制不管，就算是臨時這樣做也不行，在寫代碼時要估計到會發生的問題。
37. 提供有用的錯誤信息
提供更多易於查找錯誤細節的方式，發生問題時，要展示出儘量多的支持細節，不過別讓用戶陷入其中。
第8章 敏捷協作
38. 定期安排會面時間
使用立會(站著開的會議)可以讓團隊達成共識。保證會議短小精悍不跑題。
39. 架構師必須寫代碼
優秀的設計從積極的程式師那裏開始演化。積極的編程可以帶來深入的理解。不要使用不願意編程的架構師——不知道系統的真實情況。是無法展開設計的。
40. 實行代碼集體所有制
讓開發人員輪換完成系統不同領域中不同模組的不同任務。
41. 成為指導者
分享自己的知識很有趣——付出的同時便有收穫。還可以激勵別人獲得更好的成果，而且提升了整個團隊的實力。
42. 允許大家自己想辦法
指給他們正確的方向，而不是直接提供解決方案。每個人都能從中學到不少東西。
43. 準備好后再共享代碼
絕對不要提交尚未完成的代碼。故意簽入編譯未通過或是沒有通過單元測試的代碼，對專案來說，應該被視作為怠忽職守的犯罪行為。
44. 做代碼複查
對於提升代碼品質和降低錯誤率來說，代碼復查是無價之寶。如果以正確的方式進行，復查可以產生非常實用而高效的成果。要讓不同的開發人員在每個任務完成後復查代碼。
45. 及時通報進展與問題
發佈進展狀況，新的想法和目前正在關注的主題。不要等著別人來問專案狀態如何。
第9章 尾聲：走向敏捷
9.1 只要一個新的習慣
9.2 拯救瀕臨失敗的項目
9.3 引入敏捷：管理者指南
P.172
作為一個管理者或者團隊的帶頭人，有責任先讓整個團隊知道接下來將要發生什麼。
If you’re a manager or team lead, you need to start by getting the team all on board. Make it clear that agile development is supposed to make things easier for the developers. This is primarily for their benefit (and ultimately, the users and the organization as well). If it isn’t easier, then something is wrong.
9.4 引入敏捷：程序員指南
9.5 結束了嗎
評注來自
態度：
出現問題時，首先關注問題本身，其次再去關係責任關係。對於一個問題，不要孤立的看問題本身，要有全局觀，方法之一就是多問“為什麼”。
在需要專業技能的工作崗位上，要養成瞭解業務領域新技能的習慣（瞭解新技能能做什麼事情，其和已有技能的優勢和劣勢）。
朝著專案的目標去做
一些需求及商業的決定需要客戶的參與才能做決定，保持隨時可以給客戶演示的系統，這樣明確的需求才夠獲得。一些方法：儘早集成、並且保持一個不長的週期持續集成；實現自動化的部署，確保出現因記憶差錯而導致的失誤。
良好職業習慣的養成
養成單元測試的習慣：通過單元測試，能更好地設計介面，並為自己的代碼品質提供迅速且清楚的品質報告。
儘量用代碼本身來說明程式的意圖：良好的命名，對複雜的介面提供清晰地注釋（意圖、輸入、輸出）
對解決過的問題要有所記錄
不要放過任何警告
1. 努力爬到高處，再以蔑視的眼神輕視他人，這似乎是人類的本性。
2. 接納別人的想法，而不是盲目接受，這是受過教育的頭腦的標誌。
另一篇評注
再一篇評注
