一片論文瘦八斤，瘦下來的東西，希望交換成了知識存在腦袋裡。

論文寫完，離下一個專案的開始還有一週的時間，利用這個時間差，讀完了借來的題目中的書。就像序裡面說的，其實這就是一本關於敏捷的書，只不過說的比較委婉。

剛翻開書的時候，發現裡面確實有很多好的程式設計習慣可以借鑑，讀著讀著，發現這更是一本將團隊高效配合的書。不過我們現在做的東西大多是和導師交流，所以團隊高效合作方面的技巧暫時能用上的還比較少，有什麼體會也沒資格說，不過關於書中的另一個方面，也就是題目中的“習慣”——尤其是程式設計習慣，還是有一些收穫的。這就將書中較好的摘抄下來。

1.對事不對人，敏捷的團隊中排在首位的應該是解決問題

當Lee先生在做一個新方案介紹的時候，下面有人會說：“那樣很蠢！”（這也暗示著Lee先生也很蠢。）如果把這句話推敲一下，也許會好一點：“那樣很蠢，你忘記考慮它要執行緒安全。”事實上最合適並且最有效的表達方式應該是：“謝謝，Lee先生。但是我想知道，如果兩個使用者同時登陸會發生什麼情況？”

看出其中的不同了吧！下面來看一看對一個明顯的錯誤有哪些常見的反應：

1.否定個人能力。

2.指出明顯的缺點，並否認其觀點。

3.詢問你的隊友，並提出你的顧慮。

第三種方法沒有譴責，沒有評判，只是簡單的表達自己的觀點。讓Lee意識到這個問題，而不是讓掃他的面子。由此可以開始一次交談，而不是爭辯。

讓我們驕傲的應該是解決了問題，而不是比較誰出的主意更好

如果你沒有犯過任何錯誤，就說明你可能沒有努力去工作

開發者和質量工程師（QA）爭論某個問題是系統本身的缺陷還是系統增強功能導致的，通常沒有多大的意義。一起如此不如趕緊去修復他。

2.欲速則不達，防微杜漸

Andy（本書作者之一）以前的一個客戶遇到了一個問題。沒有一個開發者或者架構師知道他們業務領域的底層資料模型。而且，通過幾年的積累，程式碼裡有著成千上萬的+1和-1修正。再這樣髒亂的程式碼中新增新功能或者修復bug，就難逃脫髮

的的噩運。

不要急於修復一段沒能真正理解的程式碼。這種+1/-1的病症始於無形，但是很快就會讓程式碼一團糟。要解決真正的問題，不要治標不治本。

孤立的程式設計非常危險，程式碼複審是發現bug最有效的方法之一。

專案中，程式碼應該是很亮堂的，不應該有黑暗死角。

評：表示被導師親自Review的人感觸很深，程式碼亮趟是個藝術活，需要下功夫。

3.跟蹤變化

瞭解最新行情，如飢似渴的閱讀，跟上新技術，學習新技術就不再是大問題，你不需要一口氣爬上10層樓，而需要一直在攀登，所以最後看起來就像只要再上一二層。如果對所有技術都一無所知，想要馬上登上10樓，肯定會讓你喘過氣來！ 迭代和增量式的學習。每天計劃用一段時間來學習新技術，當你聽到一些不熟悉的屬於或者短語時，簡要地記錄下來。然後在計劃的時間中深入研究它。 你不需要精通所有技術，但需要清楚知道行業的動向，從而規劃你的專案和職業生涯。 評：我們有個老師，感覺很多技術他都知道，都會用，估計就是這種增量學習的成果吧。

4.打破砂鍋問到底

不停的文為什麼。不能只滿足於別人告訴你的表面現象。要不停地提問知道你明白問題的根源。

5.保持簡單

“簡單性”這個詞彙被人們大大誤解了。他並不是以為著簡陋、業餘或者能力不足。恰恰相反，相比一個過分複雜、拙劣的解決放啊，簡單的方案通常更難獲得。 怎樣才算優雅？優雅的程式碼第一眼看上去，就知道它的用處，而且很簡潔。但是這樣的解決方案不是那麼容易就想出來的。這就是說，優雅是易於理解和便是的，但是要想創建出來就困難多了。 開發可以工作的、最簡單的解決方案。除非有不可辯駁的原因，否則不要使用設計模式、原則和高難度技術之類的東西。 當你覺得所編寫的程式碼中沒有一行是多餘的，並且仍能交付全部的功能時，這種感覺就對了。這樣的程式碼容易理解和改正。 評：個人感覺這一條和奧坎姆剃刀有著很相近的意思。尤其是程式碼中，簡潔，優美，反倒是出問題的機率較少，維護容易。

6.記錄問題解決日誌

面對問題（並解決掉）是開發人員的一種生活方式。通過web尋找答案是個好方法，但是是非常耗時間的過程。有時可以找到需要的答案，有時除了找到一大堆意見和建議之外，發現不了實質性的解決方案。看到有多少人員遇到同樣的問題，也許會感覺不錯，但是我們需要的是一個解決方案。想得到更好的效果，不妨維護一個儲存曾經遇到過的問題以及解決方案的日誌。這樣當問題放生是，就不必說：”嘿，我曾碰到過這個問題，但是不記得是怎麼解決的了。“可以快速搜尋以前用過的方法。工程師們已經使用這種方式很多年了，他們稱之為每日日誌（daylog）。下面的條目可能會用得上：

1.問題發生的日期 2.問題簡述 3.解決方案詳細描述 4.引用文章或網址，以提供更多細節或相關資訊。 5.任何程式碼片段、設定或對話方塊的截圖，只要他們是解決方案的一部分，或者可以幫助更深入地理解相關細節。

要將日誌儲存為可供計算機搜尋的格式，就可以進行相關字搜尋的格式，就可以進行關鍵字搜尋以快速查詢細節了。（怎麼做到？javadoc?）

這個檔案還可以建立一個Wiki，大家一起來維護。

總結

以上就是書中的內容，大多是原話摘抄，小部分是筆（鍵）者（人）的評論。

讀完了之後，常駐於心的就是：敏捷就是要解決問題，而不是指責別人。抱著這樣的話，就有理由相信別人也是這樣想的，竟然就提高了自己的交流效率。