不過話說回來，面試中的面授算法，包括面授項目中幾乎不可能用到的算法，也不能說不合理。算法往往是學習和理解能力的試金石，難的東西都能掌握，容易的東西往往就更不用說了。有誌於上層的人將從中層獲益。反之則不然。另壹方面，雖然教科書上的算法大部分即使使用了也是直接被模塊使用的，但遺憾的是，我們搬磚的人有時候作為發明者也要做點什麽:要麽我們要把算法改進成白盒，以滿足手頭的具體需求；或者幹脆發明輪子。所以雖然面試算法本身不壹定具備，但是熟悉各種算法的人通常更容易熟悉算法的思想，所以更容易具備這裏所說的兩種能力。
那麽，算法為什麽難呢？這個問題只有兩種可能的原因:
算法本身就很難。換句話說，算法本身對於人腦來說就是壹件很難的事情。
那是壹個糟糕的演講。
下面會解釋，算法之所以被大多數人認為很難，是因為以上兩個原因都是。
我們說算法難，有兩種情況:壹種是算法難學。第二是算法設計難。對於前者，大部分人(至少我當年是這樣做的)學習算法幾乎是背得滾瓜爛熟，就像背菜譜壹樣(《菜譜》是廣大碼農喜愛的壹類書)，但算法和菜譜的區別在於，算法所包含的細節的復雜程度是菜譜的無數倍，算法的問題描述千變萬化，邏輯過程無窮無盡，往往讓人感到悲哀。相比之下，任何菜譜都只涉及幾個基本要素(所以程序員必須具備成為好廚師的潛質:d)註意，即使妳看了算法的證明，某種程度上還是“背”的(為什麽這麽說，我們後面再細說)。我自己遇到新算法基本都會看到證明，但是找到後很快就忘了。這是死記硬背的典型癥狀。如果妳也啃過算法書，我相信很有可能妳會有同感:為什麽當時明明懂了，沒多久就忘了？為什麽妳當時很懂證明，但想自己證明沒多久就發現在上交所補不上缺失的壹環？
初中學幾何證明的時候，妳會傻到背壹個定理證明嗎？不行，妳只能背誦結論。為什麽？壹方面是因為證明過程包含了很多細節。另壹方面，證明的過程是環環相扣的，只要註意壹兩個關鍵步驟就可以自己推導出來。算法的邏輯描述就像定理，證明算法的過程就像證明定理的過程。遺憾的是，與數學中許多簡潔的基本結論不同，算法的“結論”並不那麽容易背誦。在很多情況下，算法本身的邏輯幾乎包含了與其證明過程相同的信息量，甚至算法本身的邏輯就是證明過程(只要翻開壹本經典的算法書，看幾本經典的教科書算法，妳就會發現算法的邏輯與算法的證明有多麽緊密的聯系)。所以我們回到剛才的問題:妳會背數學證明嗎？既然沒人傻到背完整個證明，又何必生硬地背算法呢？
所以，不背就不背，理解算法的證明怎麽樣？理解算法的證明過程，就更容易記住算法的邏輯細節，理解記憶。然而遺憾的是，絕大多數算法書在這方面做得很差，證明很完整，邏輯也相當嚴謹。但是，似乎沒有壹個作者能夠真正還原算法發明者本人是如何得到算法以及算法證明的思維過程。按理說，證明過程應該體現這種思維過程，但在下面這個關於霍夫曼編碼的例子中，妳會看到，事實上，備受好評的CLRS和算法不僅沒有還原這壹過程，反而掩蓋了這壹過程。
必須說明的是，沒有壹個作者是故意這樣做的，但在解釋自己已經明白的東西時，任何人都會不自覺地將自己的解釋“線性化”，比如證明問題。如果妳回憶壹下高中證明平面幾何問題的經歷，妳會發現證明的過程其實充滿了“非線性”，比如試錯、聯想、逆向推導、特例、修改問題條件、窮舉等等。壹個混沌的過程，而不是像教科書上寫的那樣——引理1，引理2，定理1，定理2，壹下子直到最後的結論。這個證明過程可能很容易理解，但絕對不容易記住。過幾天，妳會忘記壹個或幾個引理，壹個或幾個關鍵技術，然後當妳想回去自己試著證明的時候，妳會發現它卡在了壹個關鍵的地方。為什麽？因為證明沒有告訴妳為什麽作者當時認為證明算法需要這樣壹個引理或者技巧，妳看了證明就知道了算法結論的原因，卻不知道算法證明過程的原因。在我們大腦的記憶系統中，新的知識必須與已有的知識聯系起來，才容易回憶起來(如何有效地學習和記憶)。鏈接越多，越容易回憶。然而，壹個飛行引理與我們現有的知識沒有任何聯系，沒有母親的孩子很容易被遺忘。為什麽還原思維過程這麽難？我曾經在《知其所以然(我)》中闡述過。
正是因為大部分算法書中悲劇的算法證明過程，很多人發現證明本身並不容易記住，所以更願意直接記住結論。當時我在數學系，考試證明過程，但是好像計算機系的考試算法證明過程很荒謬？作為壹個“工程化”的程序設計，似乎更註重使用和結果。但是如果項目中需要自己設計壹個算法呢？這時候妳最起碼要做的就是證明算法的正確性。我們在面試的時候，經常會遇到壹些算法設計的問題。我總是要求考生證明算法的正確性，因為即使是壹個看起來“正確”的算法，往往也不是那麽容易證明的。
所以絕大多數算法書從培養算法設計者的角度來說都是失敗的，比數學教育還要失敗。大部分人在初中學完平面幾何後都會做證明題(數學書不要求妳記住幾何的所有定理)，但是很多人看了壹本算法書還是壹塌糊塗，壹些基本算法都不會證明。我們壹個結論壹個結論的背，不僅很多沒用，連在壹起用的也不會證明。為什麽會有這樣的差異？因為數學教育的理想目的是讓妳成為壹個能發現新定理的科學家，但是代碼農業系的算法教育的目的更現實，是為了讓妳成為壹個能用算法做事的工程師。然而，真的有那麽簡單嗎？如果是這樣的話，連算法的結論都不用背，只要知道算法在做什麽，時空復雜度是多少就行了。
如果說上面提到的算法的難度(解釋和記憶的難度)屬於偶然復雜性，那麽算法的另壹個難點就是本質復雜性:算法設計。或者拿數學證明做類比(如果妳讀過《算法導論:壹種創造性的方法》，妳就會知道算法和數學證明有多相似。)，相比於僅僅證明，設計壹個算法的難點在於定理和證明都需要妳去探索，尤其是前者——需要妳自己去發現關鍵的定理。比起證明已知結論(妳知道結論是正確的，妳只需要把結論和條件用邏輯聯系起來)，這件事的復雜程度往往要困難壹個數量級。
壹個有趣的事實是，算法探索的過程往往包含算法證明的過程。理想的算法書應該還原算法探索的過程，讓讀者不僅能自己推導證明的過程，還能有探索新算法的能力。我這麽說是因為我是個懶人。懶人總是夢想著學點東西來達到以下兩個目的:
壹勞永逸:程序員都知道“寫壹次，到處跑”的好處，簡單多了。學了就忘了，忘了又要重新學，壹遍又壹遍的浪費生命。為什麽不能看壹次就念念不忘呢？是教的不好還是學的不好？
事半功倍:其實程序員不僅講究壹次編寫，到處運行，還講究“壹次編寫，到處使用”(也稱“復用”)。如果學習壹個算法獲得的經驗可以隨處使用，學壹個當十個，推而廣之，時間利用的效率會大大提高。怎樣才能學會最大限度的發揮外推經驗的效率？
想要做到這兩點，就必須盡可能從知識樹的“根節點”開始。雖然這是壹個美好的夢，比如尋找數學中“根節點”的夢想由來已久(“用泡利亞解題的壹點歷史”)，但哥德爾的證明讓夢想化為烏有(“永恒的黃金對角線”)；但是，這並不妨礙我們尋找更高層次的節點——更普遍的解決問題的原則和方法。所以，理想的算法書或算法講解，應該從最壹般的思維規律出發，對算法進行邏輯推導。這個過程應該盡量還原壹個“普通人”的思維過程，而不是讓人覺得“這怎麽能想到？”
以本文第壹部分提到的霍夫曼編碼為例。第壹次看到霍夫曼編碼的時候，只看到了算法描述，挺直觀的。過了兩年，我忘了，因為我不知道為什麽兩個節點的頻率加在壹起是壹個節點——如果我不知道“為什麽”，我就記不好。知道了“為什麽”就為這件事提供了必然性。如果妳不知道“為什麽”，妳可以選擇這個或那個。我們的大腦經常會把其他的東西搞混，比較容易記住那些有理有據的東西(從信息論的角度來說，壹個必然的東西的概率是1，壹個替代的東西的信息量是0，而壹個替代的東西的信息量大於0)。第二次看是下班後，終於知道需要看證明了。我拿出著名的算法，邊看邊點頭。感覺真的很好，壹看就明白為什麽要構造那樣的最優編碼樹了。可是沒過多久，我又忘記了！這次我忘了不是把兩個節點的頻率加起來算壹個，而是忘了我為什麽要這麽做，因為我不明白霍夫曼為什麽能想到我為什麽要那樣構造最優編碼樹。結果我只知道壹件事，不知道另壹件事。
必須註意的是，如果妳只關心算法的結論(也就是算法邏輯)，那麽理解算法的證明就夠了，光背算法的邏輯是很難記住的，理解了證明就容易記住很多。但要記住算法的證明，不僅要理解證明，還要理解背後的思維，也就是背後的為什麽。後者壹般很難在書籍和資料中找到，只有妳自己去揣摩。為什麽要煩這個神？只要不忘結論，不就結束了嗎？看妳想做什麽，如果妳想真正理解算法設計背後的想法，不去揣摩算法的原作者是怎麽想出來的是不可能的。