《高效程序員的45個習慣》這本書的副標題是敏捷開發修煉之道，這是一本講敏捷的書，如果你之前未接觸過敏捷，從這本書，可以了解到敏捷的核心觀點。
這里面主要講了三方面的內容，觀念，溝通，以及編碼。
觀念
我們首先從觀念來看，提觀念當然少不了敏捷宣言：
個體和交互勝過過程和工具；
可工作的軟件勝過面面俱到的文檔；
客戶的協作勝過合同談判。
響應變化勝過遵循計划；
敏捷開發改變了整個開發流程；
傳統的瀑布模型是重設計，資深的架構設計師將設計事無巨細的做出來，然后讓小兵來開發；在面對需求變更時，通常很無力；
敏捷反對通過設計來操縱開發，將重設計改為設計指導；
溝通
溝通是敏捷中最核心的部分，其中涉及到團隊溝通、與客戶的溝通。
團隊的溝通
要努力成為團隊中的一個指導者，分享你的知識。在分享知識前，你有一個准備的過程，你需要把你知道的知識有條理講給人家聽，讓他人聽懂，你這個准備和講解的過程對你來一種提升，之前一知半解的問題，在講給他人聽的過程，會理解透徹。
知識分享的過程不僅僅是通過講解的方式，文字分享也是重要的一面；這里就提到了wiki的重要性，把你的知識納入wiki，收益的就不僅僅是目前的團隊成員，更有未來的團隊，這樣你的知識得到了傳承，呵，多么了不起；
wiki寫多了，也能夠讓你的工作變得輕松，比如同事向你請教問題時，你可以給他一個鏈接“看wiki去吧，這里面很詳細”，那感覺，很棒不是？
關於wiki的好處，之前有過詳細討論, 傳送門：公司內部wiki，你建立了么？
為了達到有效溝通，敏捷提出了兩個有趣的會議：
第一個是每日站會，這是敏捷中必不可少的一個會議，就是每天15分鍾出來，進行討論，回答3個問題：
你這一天做了什么？
明天打算做什么？
遇到了什么問題？
這個站會上不是解決問題的場所，你只是提出你所遇到的問題，解決問題放在會后進行。
第二個是午餐會議，就是大伙很隨意的吃飯聊天，可由特定的一個人，分享一些書籍。當然可以是非技術領域；當然這也是一個分享的過程，能夠提升團隊的凝聚力。
除了我們語言交流外，代碼也是用來溝通的，要記住代碼閱讀的次數要遠大於大於代碼輸寫的字數。敏捷強調代碼集體所有制，就是說，代碼是大家共同所有，而不是某一個人精通某一塊。
實現代碼集體所有制的方法，是采用團隊任務輪換；不再是某一個人，一直在做某一個特定的小領域；這樣，能保證大家對整個項目都有所了解。
考慮到你寫的代碼就是給別人看的，在你會更加仔細的編寫並合理的添加注釋；
和客戶的溝通
與客戶溝通時要保證溝通工具的簡潔易懂，比如我們日常使用的word和xls表格方式，不要使用過於專業的工具或術語；
當業務上的模糊的地方時，需要由客戶來做決定，傾聽客戶的聲音。不用擔心客戶的決定導致項目需求的變更，敏捷就是來適應變更的；
爭取盡早的見到最終的客戶，如果有條件，在每次迭代完成之后，給用戶演示一下我們的模型，這樣比文字上的溝通更為直觀，也更容易發現客戶真正的需求；
當客戶發現這東西和他想要的不一樣時，要快速的響應客戶需求，盡快地把它放到下一個迭代中來。
編碼
講編碼最主要是第六章所講的內容，其中談到的規范和技巧不僅僅是適用敏捷。
比如要合理的使用技術，不能過份迷戀模式。如果為了模式而模式，反倒把系統搞復雜了，就得不償失了。
這里提倡持續集成，頻繁的集成。我們當天編寫完代碼，提交到版本庫上；系統能將這塊代碼集成到我們的整個系統中，然后跑單元測試用例和集成用例，完成之后給出詳細的報告；
可以看出，實現持續集成的前提是有一個自動化部署的環境，能讓我們在提交代碼后實現自動化部署集成，輕松增量式編程。
本書思維導圖讀書筆記:
下載：(高效程序員的45個習慣.mmap)
電子版試讀：（高效程序員的45個習慣.pdf)
Posted by: 大CC | MAR25,2013
博客：blog.me115.com [訂閱]
微博：新浪微博