前一段時間看了兩本書《高效程式設計師的 45 個習慣——敏捷開發修煉之道》和《高效能程式設計師的修煉》。書名很相似，讀完這兩本書花的時間也差不多，都是兩個星期左右。兩本書內容差別卻不小。不過，總結起來一句話：都是好書！
“變”——讀《高效程式設計師的 45 個習慣》所想到的
《高效程式設計師的 45 個習慣》原名 Practices of an Agile Developer，所以這本書主要是講敏捷開發方法與實踐的。由於對團隊和協作沒什麼清晰的概念，而且書中大多是以團隊開發為例項的，看完以後有好多地方沒太明白。所以，這本書不太適合大一的讀，估計我還需要兩年後再讀一次。
但是還是有很多收穫的，作者 Andy Hunt 和 Venkat Subramaniam 在書中傳授了很多敏捷開發的思想，不但適用於團隊，而且對獨立開發者也有很大借鑑意義。在這裡總結一下：
-
不管路走了多遠，錯了就要重新返回——要快速適應變化。
-
開發要持續不斷，切勿時續時斷。
-
態度決定一切。
-
指責不能修復 bug——出現了問題以後，首先要做的不是追究責任，而是解決問題。（原文更經典一些：Blame doesn’t fix bugs. Instead of pointing fingers, point to possible solutions. It’s the positive outcome that counts. ）
-
過程符合標準不意味著結果是正確的。結果重於過程（“結果不重要”向來都是說給失敗者的）。
-
如果你沒有犯過任何錯誤，說明你可能沒有努力工作。
-
你不需要很出色才能起步，但是你必須起步才能變得很出色。——Les Brown
-
能容納自己並不接受的想法，表明你的頭腦足夠有學識。——亞里士多德
-
如果你自己都不清楚所談論的東西，就根本不可能精確地描述它。——約翰·馮·諾依曼
-
程式碼清晰程度的優先順序應該排在執行效率之前。
-
跟蹤技術變化。
-
習慣很可能造就一個專家，但同樣也能毀了這個專家（自己想的，有點扯）——打破舊習慣很難，更難的是自己還沒有意識到這個問題。
-
選定了要走的路，就是選定了它通往的目的地。
雖然這是一本關於專案開發方法的書，作者也通篇在講開發中需要注意規避和正確的做法與心態，但是我卻從中看到了更多程式以外的東西。
作者在第一章就總結說，敏捷開發要不斷地使用反饋進行自我調整和完善。這句話真的很好，只有不斷的調整和完善才能跟上技術和設計的步伐，不至於專案交付時拿出來的是一個脫離了潮流甚至充滿錯誤設計的東西。其實對生活也是這樣。經常總結自己，當發現生活偏向某個極端時，就做一下調整，就像航海時發現偏離航線了要及時調整航向一樣，否則因為反應遲鈍帶來的痛苦與損失是要付出很多代價的，而且付出的代價往往與問題發現的時間成正比。越早發現問題，就越容易修復問題。
管理大師德魯克說∶“世界唯一不變的是變化。”真正的敵人是變化，而且你不可能打敗變化，你所能做的就是適應變化。看完這本書，個人感覺，其實就一個字就能把這本書想說的敏捷開發給概括，那就是“變”。如果能在變化中使自己變化以適應變化，見機行事，隨機應變，你就達到了“敏捷”（相關內容可以看我之前寫的 All Over Again）。
另外，書中《使用短迭代，增量釋出》一文給我留下很深印象。短迭代讓人感覺非常專注且具效率。你能看到一個實際並且確切的目標。嚴格的最終期限迫使你做出一些艱難的決策，沒有遺留下長期懸而未決的問題。如果每個迭代時間都不夠用，要麼是任務太大，要麼是迭代的時間太短。把握好自己的節奏。
重構生活
你要不斷從自己寫的程式碼中得到反饋，並且使用自動化工具不斷地構建和測試系統。在前進的過程中，你都會有意識地修改一些程式碼：在功能不變的情況下，重新設計程式碼，改善程式碼質量。這就是所謂的重構。
當你把這段話中的“程式碼”換成“生活”時，你會發現它同樣是對的。所以，就像團隊需要隔段時間重構自己專案的某些程式碼以減少 bug、精簡程式碼一樣，你也要學會重構自己的生活，來提高生活質量。
所以說，世界著名程式設計師中有很多是哲學家自己想的。
你所需要的僅僅是一個新的習慣。
“快樂”與“熱情”——《高效能程式設計師的修煉》教給我的
另一本，是 Stack Overflow 創始人之一 Jeff Atwood 的 《Effective Programming: More Than Writing Code》。這本書類似於《黑客與畫家》，文章主要取自作者的部落格 CodingHorror。看完之後，與上一本不同的是，這本書淺顯易懂，而且處處體現出作者積極向上的幽默，通過各種例項，闡述了自己對程式設計師應有的態度、學習方法、技能的看法，最後還談到了職業規劃和程式設計師的幸福，很適合初級程式設計師和學生讀。
下面是我對書中主要內容的一些筆記（主要是自己總結的，想了解更多還是去看書吧）：
-
問自己：“你究竟想過怎樣的生活？”
-
人們需要花一生的時間去學習如何有效地寫作。而且這事沒有捷徑。
-
程式設計師應該通過讀書或閱讀部落格來磨快自己的“鋸子”。
-
避免同時做多個專案，不要高估自己的能力。
-
出現問題時，儘量認為是自己的錯。
-
自己是阻止自己進步的罪魁禍首。
-
就像不要寫沒用的程式碼一樣，不要寫沒用的註釋。
-
當你需要寫註釋的時候，先看看自己能不能把程式碼寫得更易懂一些。
-
學會閱讀原始碼，不管是自己的還是別人的。
-
對於創意來說，執行是一個增倍器。它能放大創意的價值，甚至更多。（閒扯一下，你如果在 07 年之前說你有一個關於手機的棒極了的點子：它有一個智慧系統，可以裝應用；還有一個觸控式螢幕，可以用手觸控，還可以用多個手指！這個點子真是太棒了，好，給你 10 塊錢上一邊去！因為這只是個點子，不是 iPhone）
-
效能是成功產品的必備屬性。對一個網站來說，要麼很快，要麼死去。
-
很多程式設計師不會程式設計。Are you one of them?
-
軟體開發者最擅長的就是學習。
-
工作經驗年數與程式設計技能之間是沒有必然聯絡的。
-
不管出了什麼問題，都是人的問題。
-
程式設計師就像“吸血鬼”，而系統管理員就像是“狼人”。（很有意思的比喻，可以看這篇部落格Vampires (Programmers) versus Werewolves (Sysadmins)）
-
嘗試結對程式設計。（與作者在書中的觀點不太一樣，作者是結對程式設計的忠實擁護者）
-
會議是浪費工作時間的絕佳去處。（加入學生會的人應該深有感觸）
-
高效的程式設計師都有絕佳的工作環境。（這一點很重要）
-
程式是所有微小細節的集合，而細節決定成敗。
-
難以使用本身就是一個大 bug。
-
第一版做的不好，但照樣釋出。
-
傾聽使用者的聲音，但別被他們牽著鼻子走。
-
……最難的事，要搞明白你沒日沒夜地拼命工作到底是為了什麼。
提問的藝術——你喜歡問“為什麼”，這很好。但你為什麼問”為什麼”?
兩本書都提到了一點，在問“為什麼”之前，一點要想好自己為什麼問這個問題。當你問“為什麼“的時候，也許你會被反問：“為什麼你問這個問題？”所以在提問之前，想好你提問的理由，這會有助於你問出恰當的問題。
在提問之前，一定要確定：
-
問題是什麼？
-
你為這個問題做了什麼嘗試？
-
你為什麼需要答案？
歸根結底，這關乎公平：如果你想要別人花上寶貴的時間來幫助你，只有在你也花了相當的寶貴時間醞釀出一個合格的問題時才算公平。幫助別人就是幫你自己！
如果你能完全投入地向一個假想中的人或者是沒有生命的物體問一個透徹而詳盡的問題，你往往會在最後認識到你犯了某中愚蠢的錯誤，於是問題不再是問題，你也因此如釋重負。
如果你讀到這裡了，強烈建議你看下這篇 Rubber Duck Problem Solving
唯快不破
“沿著那條路走下去，一定要快。如果有什麼東西擋住了你的去路…繞開它！”
其實，作者在建立 Stack Exchange 時也用到了敏捷方法，而且“快”是 Stack Overflow 的制勝法寶。第一版做的不好，但照樣釋出，然後在不斷的使用者反饋中獲得靈感與思路，在快速迭代中完善產品。
idea 就是 shit
在國內 App 創業浪潮中，很多人都強調了創意的重要性，甚至認為有了一個想法（先不說它的好壞）就有了一點，整天把“idea”掛在嘴邊，認為自己就是下一個賈伯斯。但其實 idea 一文不值，重要的是去實現它。因為你要相信，你能想到的，別人也能想到（同樣先不說它的好壞），但你能做到的，別人不一定能做到。
如何應對初見成功後出現的複製品
當遇到自己產品的複製品時，該怎麼做呢？很多人發現有類似自己的網站或是模仿自己的 App 上線時，都變得很瘋狂，在各種社群、論壇或是問答網站表達無奈和委屈，以博得同情，或是大罵山寨者，引起眾怒。但其實這一點用也沒有，當你在哭爹喊孃的時候別人已經超過你了。我現在還沒聽說哪個開發者把山寨貨告上法庭並打敗對方的事。看看 Jeff 在面對 Stack Overflow 的複製品時是怎麼做的，
現在市面上已經出現了一些 Stack Overflow 引擎的複製品。我想說他們乾的不錯！……我們的使命是讓網際網路變得更好（哪怕我們只能帶來一些細微的改進）。……我們沒曾想過要推翻誰或者佔有什麼東西。所以在這個過程中，如果有任何東西擋住了我們的路，請放心，我們不會大打出手。我們會繞開。然後繼續向前，快速進步。因此，如果那些抄襲者想要跟上我們的話，他們也得行動快點。
懂了嗎？就是一個字——“快”。只有比你的對手快，你才能打敗那些山寨者。Chrome 為什麼會在短短几年打敗 IE（但人家仍是市場份額老大）和 Firefox，就是因為它極速的迭代速度。
前幾天在知乎上看到有人問“如何在國內盜版橫行的 Android 市場上存活”，我是這樣回答的
兩條路，要麼一直創新讓別人趕不上，要麼放棄這個市場。
其實我是推薦後者的。
自己關於提高效率的想法
效率低下的罪魁禍首往往不是資訊不足，而是資訊過多。
希捷前 CEO Bill Watkins 在 06 年曾放出一個讓很多人驚掉眼鏡的說法：“醒醒吧，硬碟是不能改變這個世界的。它能做的就是幫助人們儲存更多的垃圾檔案和色情片。”雖然的確有些誇張了，但是面對越來越大的硬碟，想一下，你真的需要那麼多空間來存放那麼多檔案嗎？
如果想做到“敏捷”和“高效”，就必須輕裝上陣，因此：
-
桌面上不放任何東西
-
清理硬碟
-
系統裡少裝程式
-
一次只開一個程式
-
適時斷網
＊以上按有效程度排序
如果你看到這裡了，我的建議是，《高效程式設計師的 45 個習慣——敏捷開發修煉之道》和《高效能程式設計師的修煉》兩本書你一定要讀。
One more thing
Everybody in this country should learn how to program a computer,because it teaches you how to think.
– Steve Jobs