溝通至上 《高效程式員的45個習慣》讀書筆記

《高效程式員的45個習慣》這本書的副标題是靈活開發修煉之道，這是一本講靈活的書，如果你之前未接觸過靈活，從這本書，可以了解到靈活的核心觀點。

這裡面主要講了三方面的内容，觀念，溝通，以及編碼。

觀念

我們首先從觀念來看，提觀念當然少不了靈活宣言：

個體和互動勝過過程和工具；

可工作的軟體勝過面面俱到的文檔；

客戶的協作勝過合同談判。

響應變化勝過遵循計劃；

靈活開發改變了整個開發流程；

傳統的瀑布模型是重設計，資深的架構設計師将設計事無巨細的做出來，然後讓小兵來開發；在面對需求變更時，通常很無力；

靈活反對通過設計來操縱開發，将重設計改為設計指導；

溝通

溝通是靈活中最核心的部分，其中涉及到團隊溝通、與客戶的溝通。

團隊的溝通

要努力成為團隊中的一個指導者，分享你的知識。在分享知識前，你有一個準備的過程，你需要把你知道的知識有條理講給人家聽，讓他人聽懂，你這個準備和講解的過程對你來一種提升，之前一知半解的問題，在講給他人聽的過程，會了解透徹。

知識分享的過程不僅僅是通過講解的方式，文字分享也是重要的一面；這裡就提到了wiki的重要性，把你的知識納入wiki，收益的就不僅僅是目前的團隊成員，更有未來的團隊，這樣你的知識得到了傳承，呵，多麼了不起；

wiki寫多了，也能夠讓你的工作變得輕松，比如同僚向你請教問題時，你可以給他一個連結“看wiki去吧，這裡面很詳細”，那感覺，很棒不是？

關于wiki的好處，之前有過詳細讨論, 傳送門：公司内部wiki，你建立了麼？

為了達到有效溝通，靈活提出了兩個有趣的會議：

第一個是每日站會，這是靈活中必不可少的一個會議，就是每天15分鐘出來，進行讨論，回答3個問題：

你這一天做了什麼？

明天打算做什麼？

遇到了什麼問題？

這個站會上不是解決問題的場所，你隻是提出你所遇到的問題，解決問題放在會後進行。

第二個是午餐會議，就是大夥很随意的吃飯聊天，可由特定的一個人，分享一些書籍。當然可以是非技術領域；當然這也是一個分享的過程，能夠提升團隊的凝聚力。

除了我們語言交流外，代碼也是用來溝通的，要記住代碼閱讀的次數要遠大于大于代碼輸寫的字數。靈活強調代碼集體所有制，就是說，代碼是大家共同所有，而不是某一個人精通某一塊。

實作代碼集體所有制的方法，是采用團隊任務輪換；不再是某一個人，一直在做某一個特定的小領域；這樣，能保證大家對整個項目都有所了解。

考慮到你寫的代碼就是給别人看的，在你會更加仔細的編寫并合理的添加注釋；

和客戶的溝通

與客戶溝通時要保證溝通工具的簡潔易懂，比如我們日常使用的word和xls表格方式，不要使用過于專業的工具或術語；

當業務上的模糊的地方時，需要由客戶來做決定，傾聽客戶的聲音。不用擔心客戶的決定導緻項目需求的變更，靈活就是來适應變更的；

争取盡早的見到最終的客戶，如果有條件，在每次疊代完成之後，給使用者示範一下我們的模型，這樣比文字上的溝通更為直覺，也更容易發現客戶真正的需求；

當客戶發現這東西和他想要的不一樣時，要快速的響應客戶需求，盡快地把它放到下一個疊代中來。

編碼

講編碼最主要是第六章所講的内容，其中談到的規範和技巧不僅僅是适用靈活。

比如要合理的使用技術，不能過份迷戀模式。如果為了模式而模式，反倒把系統搞複雜了，就得不償失了。

這裡提倡持續內建，頻繁的內建。我們當天編寫完代碼，送出到版本庫上；系統能将這塊代碼內建到我們的整個系統中，然後跑單元測試用例和內建用例，完成之後給出詳細的報告；

可以看出，實作持續內建的前提是有一個自動化部署的環境，能讓我們在送出代碼後實作自動化部署內建，輕松增量式程式設計。

本書思維導圖讀書筆記: