前一段時(shí)間看了兩本書(shū)《高效程序員的45個(gè)習(xí)慣——敏捷開(kāi)發(fā)修煉之道》和《高效能程序員的修煉》。書(shū)名很相似，讀完這兩本書(shū)花的時(shí)間也差不多，都是兩個(gè)星期左右。兩本書(shū)內(nèi)容差別卻不小。不過(guò)，總結(jié)起來(lái)一句話：都是好書(shū)！

“變”——讀《高效程序員的45個(gè)習(xí)慣》所想到的

《高效程序員的45個(gè)習(xí)慣》原名Practices of an Agile Developer，所以這本書(shū)主要是講敏捷開(kāi)發(fā)方法與實(shí)踐的。由于對(duì)團(tuán)隊(duì)和協(xié)作沒(méi)什么清晰的概念，而且書(shū)中大多是以團(tuán)隊(duì)開(kāi)發(fā)為實(shí)例的，看完以后有好多地 方?jīng)]太明白。所以，這本書(shū)不太適合大一的讀，估計(jì)我還需要兩年后再讀一次。

但是還是有很多收獲的，作者Andy Hunt和Venkat Subramaniam在書(shū)中傳授了很多敏捷開(kāi)發(fā)的思想，不但適用于團(tuán)隊(duì)，而且對(duì)獨(dú)立開(kāi)發(fā)者也有很大借鑒意義。在這里總結(jié)一下：

不管路走了多遠(yuǎn)，錯(cuò)了就要重新返回——要快速適應(yīng)變化。

開(kāi)發(fā)要持續(xù)不斷，切勿時(shí)續(xù)時(shí)斷。

態(tài)度決定一切。

指責(zé)不能修復(fù)bug——出現(xiàn)了問(wèn)題以后，首先要做的不是追究責(zé)任，而是解決問(wèn)題。（原文更經(jīng)典一些：Blame doesn’t fix bugs. Instead of pointing fingers， point to possible solutions. It’s the positive outcome that counts. ）

過(guò)程符合標(biāo)準(zhǔn)不意味著結(jié)果是正確的。結(jié)果重于過(guò)程（“結(jié)果不重要”向來(lái)都是說(shuō)給失敗者的）。

如果你沒(méi)有犯過(guò)任何錯(cuò)誤，說(shuō)明你可能沒(méi)有努力工作。

你不需要很出色才能起步，但是你必須起步才能變得很出色?！狶es Brown

能容納自己并不接受的想法，表明你的頭腦足夠有學(xué)識(shí)?！獊喞锸慷嗟?/p>

如果你自己都不清楚所談?wù)摰臇|西，就根本不可能精確地描述它?！s翰·馮·諾依曼

代碼清晰程度的優(yōu)先級(jí)應(yīng)該排在執(zhí)行效率之前。

跟蹤技術(shù)變化。

習(xí)慣很可能造就一個(gè)專家，但同樣也能毀了這個(gè)專家（自己想的，有點(diǎn)扯）——打破舊習(xí)慣很難，更難的是自己還沒(méi)有意識(shí)到這個(gè)問(wèn)題。

選定了要走的路，就是選定了它通往的目的地。

雖然這是一本關(guān)于項(xiàng)目開(kāi)發(fā)方法的書(shū)，作者也通篇在講開(kāi)發(fā)中需要注意規(guī)避和正確的做法與心態(tài)，但是我卻從中看到了更多程序以外的東西。

作者在第一章就總結(jié)說(shuō)，敏捷開(kāi)發(fā)要不斷地使用反饋進(jìn)行自我調(diào)整和完善。這句話真的很好，只有不斷的調(diào)整和完善才能跟上技術(shù)和設(shè)計(jì)的步伐，不至于項(xiàng)目 交付時(shí)拿出來(lái)的是一個(gè)脫離了潮流甚至充滿錯(cuò)誤設(shè)計(jì)的東西。其實(shí)對(duì)生活也是這樣。經(jīng)常總結(jié)自己，當(dāng)發(fā)現(xiàn)生活偏向某個(gè)極端時(shí)，就做一下調(diào)整，就像航海時(shí)發(fā)現(xiàn)偏 離航線了要及時(shí)調(diào)整航向一樣，否則因?yàn)榉磻?yīng)遲鈍帶來(lái)的痛苦與損失是要付出很多代價(jià)的，而且付出的代價(jià)往往與問(wèn)題發(fā)現(xiàn)的時(shí)間成正比。越早發(fā)現(xiàn)問(wèn)題，就越容易 修復(fù)問(wèn)題。

管理大師德魯克說(shuō)∶“世界唯一不變的是變化?！闭嬲臄橙耸亲兓夷悴豢赡艽驍∽兓?，你所能做的就是適應(yīng)變化?？赐赀@本書(shū)，個(gè)人感覺(jué)，其實(shí)就一 個(gè)字就能把這本書(shū)想說(shuō)的敏捷開(kāi)發(fā)給概括，那就是“變”。如果能在變化中使自己變化以適應(yīng)變化，見(jiàn)機(jī)行事，隨機(jī)應(yīng)變，你就達(dá)到了“敏捷”（相關(guān)內(nèi)容可以看我 之前寫(xiě)的All Over Again）。

另外，書(shū)中《使用短迭代，增量發(fā)布》一文給我留下很深印象。短迭代讓人感覺(jué)非常專注且具效率。你能看到一個(gè)實(shí)際并且確切的目標(biāo)。嚴(yán)格的最終期限迫使 你做出一些艱難的決策，沒(méi)有遺留下長(zhǎng)期懸而未決的問(wèn)題。如果每個(gè)迭代時(shí)間都不夠用，要么是任務(wù)太大，要么是迭代的時(shí)間太短。把握好自己的節(jié)奏。

重構(gòu)生活

你要不斷從自己寫(xiě)的代碼中得到反饋，并且使用自動(dòng)化工具不斷地構(gòu)建和測(cè)試系統(tǒng)。在前進(jìn)的過(guò)程中，你都會(huì)有意識(shí)地修改一些代碼：在功能不變的情況下，重新設(shè)計(jì)代碼，改善代碼質(zhì)量。這就是所謂的重構(gòu)。

當(dāng)你把這段話中的“代碼”換成“生活”時(shí)，你會(huì)發(fā)現(xiàn)它同樣是對(duì)的。所以，就像團(tuán)隊(duì)需要隔段時(shí)間重構(gòu)自己項(xiàng)目的某些代碼以減少bug、精簡(jiǎn)代碼一樣，你也要學(xué)會(huì)重構(gòu)自己的生活，來(lái)提高生活質(zhì)量。

所以說(shuō)，世界著名程序員中有很多是哲學(xué)家自己想的。

你所需要的僅僅是一個(gè)新的習(xí)慣。

“快樂(lè)”與“熱情”——《高效能程序員的修煉》教給我的

另一本，是Stack Overflow創(chuàng)始人之一Jeff Atwood的 《高效能程序員的修煉》。這本書(shū)類(lèi)似于《黑客與畫(huà)家》，文章主要取自作者的博客CodingHorror?？赐曛?，與上一本不同的是，這本書(shū)淺顯易懂，而且處處體現(xiàn)出作者積極向上的幽默，通過(guò)各種實(shí)例，闡述了自己對(duì)程序員應(yīng)有的態(tài)度、學(xué)習(xí)方法、技能的看法，最后還談到了職業(yè)規(guī)劃和程序員的幸福，很適合初級(jí)程序員和學(xué)生讀。

下面是我對(duì)書(shū)中主要內(nèi)容的一些筆記（主要是自己總結(jié)的，想了解更多還是去看書(shū)吧）：

問(wèn)自己：“你究竟想過(guò)怎樣的生活？”

人們需要花一生的時(shí)間去學(xué)習(xí)如何有效地寫(xiě)作。而且這事沒(méi)有捷徑。

程序員應(yīng)該通過(guò)讀書(shū)或閱讀博客來(lái)磨快自己的“鋸子”。

避免同時(shí)做多個(gè)項(xiàng)目，不要高估自己的能力。

出現(xiàn)問(wèn)題時(shí)，盡量認(rèn)為是自己的錯(cuò)。

自己是阻止自己進(jìn)步的罪魁禍?zhǔn)住?/p>

就像不要寫(xiě)沒(méi)用的代碼一樣，不要寫(xiě)沒(méi)用的注釋。

當(dāng)你需要寫(xiě)注釋的時(shí)候，先看看自己能不能把代碼寫(xiě)得更易懂一些。

學(xué)會(huì)閱讀源代碼，不管是自己的還是別人的。

對(duì)于創(chuàng)意來(lái)說(shuō)，執(zhí)行是一個(gè)增倍器。它能放大創(chuàng)意的價(jià)值，甚至更多。（閑扯一下，你如果在07年之前說(shuō)你有一個(gè)關(guān)于手機(jī)的棒極了的點(diǎn)子：它有 一個(gè)智能系統(tǒng)，可以裝應(yīng)用；還有一個(gè)觸摸屏，可以用手觸摸，還可以用多個(gè)手指！這個(gè)點(diǎn)子真是太棒了，好，給你10塊錢(qián)上一邊去！因?yàn)檫@只是個(gè)點(diǎn)子，不是 iPhone）

性能是成功產(chǎn)品的必備屬性。對(duì)一個(gè)網(wǎng)站來(lái)說(shuō)，要么很快，要么死去。

很多程序員不會(huì)編程。Are you one of them？

軟件開(kāi)發(fā)者最擅長(zhǎng)的就是學(xué)習(xí)。

工作經(jīng)驗(yàn)?zāi)陻?shù)與編程技能之間是沒(méi)有必然聯(lián)系的。

不管出了什么問(wèn)題，都是人的問(wèn)題。

程序員就像“吸血鬼”，而系統(tǒng)管理員就像是“狼人”。（很有意思的比喻，可以看這篇博客Vampires （Programmers） versus Werewolves （Sysadmins））

嘗試結(jié)對(duì)編程。（與作者在書(shū)中的觀點(diǎn)不太一樣，作者是結(jié)對(duì)編程的忠實(shí)擁護(hù)者）

會(huì)議是浪費(fèi)工作時(shí)間的絕佳去處。（加入學(xué)生會(huì)的人應(yīng)該深有感觸）

高效的程序員都有絕佳的工作環(huán)境。（這一點(diǎn)很重要）

程序是所有微小細(xì)節(jié)的集合，而細(xì)節(jié)決定成敗。

難以使用本身就是一個(gè)大bug。

第一版做的不好，但照樣發(fā)布。

傾聽(tīng)用戶的聲音，但別被他們牽著鼻子走。

……最難的事，要搞明白你沒(méi)日沒(méi)夜地拼命工作到底是為了什么。

提問(wèn)的藝術(shù)——你喜歡問(wèn)“為什么”，這很好。但你為什么問(wèn)”為什么”？

兩本書(shū)都提到了一點(diǎn)，在問(wèn)“為什么”之前，一點(diǎn)要想好自己為什么問(wèn)這個(gè)問(wèn)題。當(dāng)你問(wèn)“為什么“的時(shí)候，也許你會(huì)被反問(wèn)：“為什么你問(wèn)這個(gè)問(wèn)題？”所以在提問(wèn)之前，想好你提問(wèn)的理由，這會(huì)有助于你問(wèn)出恰當(dāng)?shù)膯?wèn)題。

在提問(wèn)之前，一定要確定：

問(wèn)題是什么？

你為這個(gè)問(wèn)題做了什么嘗試？

你為什么需要答案？

歸根結(jié)底，這關(guān)乎公平：如果你想要?jiǎng)e人花上寶貴的時(shí)間來(lái)幫助你，只有在你也花了相當(dāng)?shù)膶氋F時(shí)間醞釀出一個(gè)合格的問(wèn)題時(shí)才算公平。幫助別人就是幫你自己！

如果你能完全投入地向一個(gè)假想中的人或者是沒(méi)有生命的物體問(wèn)一個(gè)透徹而詳盡的問(wèn)題，你往往會(huì)在最后認(rèn)識(shí)到你犯了某中愚蠢的錯(cuò)誤，于是問(wèn)題不再是問(wèn)題，你也因此如釋重負(fù)。

如果你讀到這里了，強(qiáng)烈建議你看下這篇Rubber Duck Problem Solving

唯快不破

“沿著那條路走下去，一定要快。如果有什么東西擋住了你的去路…繞開(kāi)它！”

其實(shí)，作者在建立Stack Exchange時(shí)也用到了敏捷方法，而且“快”是Stack Overflow的制勝法寶。第一版做的不好，但照樣發(fā)布，然后在不斷的用戶反饋中獲得靈感與思路，在快速迭代中完善產(chǎn)品。

idea就是shit

在國(guó)內(nèi)App創(chuàng)業(yè)浪潮中，很多人都強(qiáng)調(diào)了創(chuàng)意的重要性，甚至認(rèn)為有了一個(gè)想法（先不說(shuō)它的好壞）就有了一點(diǎn)，整天把“idea”掛在嘴邊，認(rèn)為自己 就是下一個(gè)喬布斯。但其實(shí)idea一文不值，重要的是去實(shí)現(xiàn)它。因?yàn)槟阋嘈?，你能想到的，別人也能想到（同樣先不說(shuō)它的好壞），但你能做到的，別人不一 定能做到。

如何應(yīng)對(duì)初見(jiàn)成功后出現(xiàn)的復(fù)制品

當(dāng)遇到自己產(chǎn)品的復(fù)制品時(shí)，該怎么做呢？很多人發(fā)現(xiàn)有類(lèi)似自己的網(wǎng)站或是模仿自己的App上線時(shí)，都變得很瘋狂，在各種社區(qū)、論壇或是問(wèn)答網(wǎng)站表達(dá) 無(wú)奈和委屈，以博得同情，或是大罵山寨者，引起眾怒。但其實(shí)這一點(diǎn)用也沒(méi)有，當(dāng)你在哭爹喊娘的時(shí)候別人已經(jīng)超過(guò)你了。我現(xiàn)在還沒(méi)聽(tīng)說(shuō)哪個(gè)開(kāi)發(fā)者把山寨貨告 上法庭并打敗對(duì)方的事?？纯碕eff在面對(duì)Stack Overflow的復(fù)制品時(shí)是怎么做的，

現(xiàn)在市面上已經(jīng)出現(xiàn)了一些Stack Overflow引擎的復(fù)制品。我想說(shuō)他們干的不錯(cuò)！……我們的使命是讓互聯(lián)網(wǎng)變得更好（哪怕我們只能帶來(lái)一些細(xì)微的改進(jìn)）。……我們沒(méi)曾想過(guò)要推翻誰(shuí)或 者占有什么東西。所以在這個(gè)過(guò)程中，如果有任何東西擋住了我們的路，請(qǐng)放心，我們不會(huì)大打出手。我們會(huì)繞開(kāi)。然后繼續(xù)向前，快速進(jìn)步。因此，如果那些抄襲者想要跟上我們的話，他們也得行動(dòng)快點(diǎn)。

懂了嗎？就是一個(gè)字——“快”。只有比你的對(duì)手快，你才能打敗那些山寨者。Chrome為什么會(huì)在短短幾年打敗IE（但人家仍是市場(chǎng)份額老大）和Firefox，就是因?yàn)樗鼧O速的迭代速度。

前幾天在知乎上看到有人問(wèn)“如何在國(guó)內(nèi)盜版橫行的Android市場(chǎng)上存活”，我是這樣回答的

兩條路，要么一直創(chuàng)新讓別人趕不上，要么放棄這個(gè)市場(chǎng)。

其實(shí)我是推薦后者的。

自己關(guān)于提高效率的想法

效率低下的罪魁禍?zhǔn)淄皇切畔⒉蛔悖切畔⑦^(guò)多。

希捷前CEO Bill Watkins在06年曾放出一個(gè)讓很多人驚掉眼鏡的說(shuō)法：“醒醒吧，硬盤(pán)是不能改變這個(gè)世界的。它能做的就是幫助人們存儲(chǔ)更多的垃圾文件和色情片?！彪m 然的確有些夸張了，但是面對(duì)越來(lái)越大的硬盤(pán)，想一下，你真的需要那么多空間來(lái)存放那么多文件嗎？

如果想做到“敏捷”和“高效”，就必須輕裝上陣，因此：

桌面上不放任何東西

清理硬盤(pán)

系統(tǒng)里少裝程序

一次只開(kāi)一個(gè)程序

適時(shí)斷網(wǎng)

＊以上按有效程度排序

如果你看到這里了，我的建議是，《高效程序員的45個(gè)習(xí)慣——敏捷開(kāi)發(fā)修煉之道》和《高效能程序員的修煉》兩本書(shū)你一定要讀。