0、註明
本文內容摘選自《高效程序員的10個習慣（中文精選版）Practice agile developer-InfoQ》，文檔內容稍加整理與總結而成。
1、作者
Venkat Subramania 等
2、節選
《高效程序員的45個習慣敏捷開發修煉之道》
3、軟件開發之內功修煉口訣
迭代開發，價值優先；
分解任務，真實進度；
站立會議，交流暢通；
用戶參與，調整方向；
結對編程，代碼質量；
測試驅動，安全可靠；
持續集成，儘早反饋；
自動部署，一鍵安裝；
定期回顧，持續改進；
不斷學習，提高能力。
4、習慣1：對事不對人
4.1、對待一個人出現明顯錯誤有哪些常見的反應
（1）否定個人能力；
===》堅決不可取，殺敵一千，自損八百
- 指出明顯的缺點，並否定其觀點；
===》觀點雖正確，但表達不妥當；
- 詢問你的同事，並提出你的顧慮
===》正確的表達方式
Q1:現實中你會選擇哪一個？注意第一意識裏的選擇是什麼。
INFO1：引導性地提出一個問題或疑問，從而讓對方自己意識到問題的存在是一個不錯的技巧。
INFO2：要專業而不是自我。
INFO3：把重點放在解決問題上，而不是極力證明誰的主意更好。
INFO4：團隊中的每個人都有自由表達觀點的權利（觀點對與錯不是重點，重點是表達觀點）。
INFO5:你不需要很出色才能起步，但是你必須起步才能變得更出色。
INFO6：能容納自己不能接受的想法，說明你足夠有學識。----亞里士多德
4.2、一些有效的特殊“招式”
1、設定最終期限
沒有最好的答案，只有更合適的答案。
2、逆向思維
判斷一個方案的優缺點時少帶一點個人情感。
3、設立仲裁人
會議開始時，選擇一個仲裁人作爲本次會議的決策者。
4、支持已經做出的決定
5、習慣2：跟蹤變化
5.1、唯有變化是永恆的。
5.2、如何跟上技術變化的幾個建議
1、迭代和增量式學習
每天學習一點新知識，時間不需要很長，貴在堅持。
2、瞭解最新行情
3、參加本地用戶組活動
4、儘可能的參加研討會議
5、如飢似渴的閱讀
6、你不需要精通所有技術（也不太可能），但需要知道行業的動向，從而規劃你的職業生涯。
6、習慣3：讓設計指導而不是操縱開發
INFO1：好的設計應該是正確的，而不是精確的。它是目標，不是具體的處方。
INFO2:不要在前期做大量的設計。
INFO3:白板、草圖、便利貼都是非常好的設計工具。複雜的建模工具只會分散你的精力，而不是啓發你的工作。
7、習慣4：提早實現自動化部署
INFO 1:一開始就進行全面的部署，而不是等到項目的尾期。
INFO 2:系統的安裝或部署應該簡單、可靠及可重複。
INFO 3:在沒有詢問及徵得用戶同意前，安裝程序絕對不能刪除用戶數據。
8、習慣5：度量真實進度
INFO 1:判斷工作進度最好看實際花費的時間而不是估計的時間。
INFO2:誠實非常重要，隱瞞真相毫無意義。
INFO3:清楚項目的真實進度，是一項強大的技術。
INFO4:Scrum方法中的sprint
9、習慣6：用代碼溝通
INFO 1:DRY原則，Don’t Repeater Yourself。
INFO 2:不要用註釋包括你的代碼。
Don’t comment to cover your code.
INFO 3:通過名稱來進行魔法控制，是文學和神話中一種常用的主題，在軟件開發中也是如此。
INFO 4:代碼能夠自解釋而不用依賴註釋是一件美好的事情。
INFO 5:解釋代碼做了什麼的註釋用處不大，相反，註釋應該說明爲什麼這樣寫代碼。
INFO 6:當重寫方法時，保留描述原有方法意圖和約束的註釋。
10、習慣7：編寫高內聚的代碼
INFO 1：內聚性用來評估一個組件（包、模塊或配件）中成員的功能相關性。內聚程度高，
表明各個成員共同完成了一個功能特性或是一組功能特性。內聚程度低的話，表
明各個成員提供的功能是互不相干的。
INFO 2:類也要遵循內聚性。如果一個類的方法和屬性共同完成了一個功能（或是一系列
緊密相關的功能），這個類就是內聚的。
INFO 3:讓類的功能儘量集中，讓組件儘量小。
INFO 4: 有可能會把一些東西拆分成很多微小的部分，而使其失去了實用價值。當你需
要一隻襪子的時候，一盒棉線不能帶給你任何幫助。
11、習慣8：根據契約進行替換
INFO 1:任何繼承後得到的派生類對象，必須可以替換
任何被使用的基類對象，而且使用者不必知道任何差異。換句話說，某段代碼如
果使用了基類中的方法，就必須能夠使用派生類的對象，並且自己不必進行任何
修改。
INFO 2:針對is-a關係使用繼承；針對has-a或uses-a關係使用委託。
INFO 3:那麼繼承和委託分別在什麼時候使用呢？
（1）如果新類可以替換已有的類，並且它們之間的關係可以通過is-a來描述，就要
使用繼承。
（2） 如果新類只是使用已有的類，並且兩者之間的關係可以描述爲has-a或是uses-a，
就使用委託吧。
INFO 4:相對繼承來說，委託更加靈活，適應力也更強。
12、習慣9：報告所有的異常
INFO 1:從事任何編程工作，都要考慮事物正常狀況下是如何運作的。不過更應該想一想，
當出現問題——也就是事情沒有按計劃進行時，會發生什麼。
INFO 2:處理或是向上傳播所有的異常。不要將它們壓制不管，就算是臨時這樣
做也不行。在寫代碼時要估計到會發生的問題。
INFO 3: 決定由誰來負責處理異常是設計工作的一部分。
INFO 4:不是所有的問題都應該拋出異常。
13、習慣10：做代碼複查
INFO 1:用戶是最好的測試人員。
INFO 2:代碼複查和缺陷移除
要尋找深藏不露的程序bug，正式地進行代碼檢查，其效果是任何已知形式測
試的兩倍，而且是移除80%缺陷的唯一已知方法。
——Capers Jones的《估算軟件成本》
INFO 3:代碼複查最基本的檢查列表
（1）代碼能否被讀懂和理解？
（2） 是否有任何明顯的錯誤？
（3） 代碼是否會對應用的其他部分產生不良影響？
（4） 是否存在重複的代碼（在複查的這部分代碼中，或是在系統的其他部分代碼）？
（5） 是否存在可以改進或重構的部分？
INFO 4:對於提升代碼質量和降低錯誤率來說，代碼複查是無價之寶。
INFO 5:不進行思考、類似於橡皮圖章一樣的代碼複查沒有任何價值。
INFO 6: 同樣的功能，不同開發人員的代碼實現可能不同。差異並不意味着不好。除非
你可以讓某段代碼明確變得更好，否則不要隨意批評別人的代碼。
INFO 7: 要確保代碼複查參與人員得到每次複查活動的反饋。作爲結果，要讓每個人知
道複查完成後所採取的行動。
