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