其實……我想說……演算法並非數學……（廢話貼，業內的人就不用看了 *^_^*）

寫到這個標題，就知道差不多又要有爭議了。其實，對於業內的人，真正的“爭議”是沒有的，每個幹過這行的人都知道這回事兒，只不過死神多事，喜歡把地球人都知道的東西用不怎麼精練的語言，寫到自己的Blog上而已。醜話在先，請眾位大大拍磚請對準目標，不要砸到花花草草，更不要破壞社會主義和諧社會的主旋律。

演算法是什麼呢？手邊一本演算法書，一翻開，不是數學，就是邏輯，再多的就是資料結構。讓人以為，演算法大抵就是這些東西。既然說程式是演算法和資料結構為核心的，那麼，是不是就意味著數學和邏輯最重要呢？

在大學，第一個遇到的謊言基本上就是這條，高年級學長來看我們，就頗為語重心長地對我們說：“小弟弟呀，小妹妹呀，一定要學好數學呀，一定要學好英語呀，數學和英語沒有學好，就等於沒經過大學呀……”

在那時，對世界的認識還遠沒那麼深刻，誤入騙局也是很正常的。如果說一個人的大學，其價值就僅限於學好兩個學科，這大抵就相當於說，一個人的大學，其價值就在於找到另一半一樣——只不過是少男少女們夢想中的世界而已。有則加冕，沒有，也說明不了什麼，因為四年不是一輩子，也決定不了一輩子。決定一輩子的，是每時每刻的行動，在關鍵時刻把握機會的勇氣，在低落時願意蟄伏、冬眠的耐心，以及永不言敗的信念。

數學構成了演算法，只因為他是電腦的基礎？但是你看誰現在去做一個軟體還會去考慮0101編碼流的問題？會去考慮什麼微積分、機率論？電腦的世界，是一個開放的，多層次的，多極化的世界。越接近底層的，做的人越少——因為市場不會需要那麼多。作業系統，全世界來他個數千萬種，可以嗎？那當然是不可以的。但是，軟體的數量卻不會下千萬了吧？為什嗎？這個學過唯物辯證法的應該都可以自己推論到：“活的必須立於死的之上”。指令集不死，就不能有立於指令集之上的編譯、連結器；編譯、連結器不死，就不能有基於這些編譯連結器的作業系統；作業系統不死，就不能有基於作業系統的軟體；軟體不死，就不能有基於這些軟體的外掛和外掛程式。

很多時候，我們手邊有很多選擇，而不是需要自己重新發明輪子，否則OO、GP和重用就沒必要誕生了。以遊戲引擎來說，除非必要，很多時候，我們在避免讓使用者直接去做數學運算——否則為什麼要提供個SetPosition、SetRotation之類的？告訴使用者你直接自己用矩陣和行列式去算，Over～。但那樣的話，使用者只會對你說一句話：“你玷汙了自己的責任！”使用者之所以要使用引擎，就是要避免太多邏輯不相干的東西：很多時候，數學也是其一。我在考慮飛彈打坦克的時候，當然會去做一下加減乘除，但是當我做路徑計算的時候，我卻希望物理系統能把一切都搞定別讓這些東西來煩我，來影響My Code品質和可讀性。沒有人喜歡讀一個遊戲邏輯代碼的時候讀到一堆物理和數學演算法的。看到的只會破口大罵：“作引擎的！給我死出來！把這些給我封裝了！”

數學，太形而下的數學或許不能稱為數學，不登大雅之堂，不能放到大學的課堂裡玷汙教授們的智慧，但，太形而上的數學，難道就應該放到工程之中，玷汙工程人員的時間和空間嗎？這不是理由。不要把自己看得太高貴，正如不能把自己看得太低俗一樣——任何問題，都應該用平靜的心態，考慮對方的感受。數學並不是一切，沒用的數學和沒用的代碼一樣，垃圾就是垃圾。

在一個寫遊戲項目的人的眼中，矩陣A叉乘矩陣B大抵是沒有什麼吸引力的，他的主要工作是很具體的。美國鬼子每秒鐘六發的火力強度，把土、樹枝甚至樹榦都轟到了天上，如何表現？美國鬼子咣咣衝上上甘嶺來，（為突出真實感）怎麼讓這幫傻子不要站的那麼密集？（背景上）我軍機槍手突突猛射，手榴彈砰砰猛扔，怎麼樣能保證別在同螢幕內顯示太多的炸點，以防粒子系統超載？我軍狙擊手怎麼優先尋找鬼子的指揮官K掉？眼看到陣地將要丟失，一個英雄緊握爆破筒，向著步話機大喊一聲“向我開炮”，縱身一躍，同上來的泡菜和鬼子同歸於盡，怎麼突出這悲壯而偉大的氣氛？！………。這些東西沒一個屬於微積分、組合數學、線性代數的處理範疇的，也不要自說自話的告訴我寫這些玩意兒得需要有多高深的數學知識——隨隨便便一個有起碼邏輯能力的人，只要告訴他指令碼怎麼寫，花點時間熟悉熟悉都能寫出來——當然前提是得有一個好的中介層，把能封裝的都封裝了。

我想問：這些是演算法嗎？你說不是，當然，它或許不是你認為的演算法，但是，它卻是組成遊戲的成千上萬的邏輯單位中的一個。

做企業軟體，沒做過，但只怕更甚。使用者的需求、設計，很多時候，編碼做的只不過是UI介面上，按了A處理A，按了B，關掉C，按了D，開啟C之類的工作。

我想問：這是演算法嗎？你又說不是，當然，它不是你心中的演算法，但是，它卻是組成整個項目的成千上萬邏輯單位中的一組。

演算法到底是什嗎？你說，演算法就是那些個演算法教材上寫的那些：排序呀，圖論呀，雜湊表呀，二叉樹呀……我哼哼冷笑，如果軟體設計到了21世紀，還得要像半個世紀前那樣全民排序全民鏈表，那我們這些搞軟體的就可以集體自殺以謝國民了！或者是集體挖坑自己把自己坑了免得讓人批判，揪鬥，住牛棚，扔狗窩——軟體作了半個世紀，我們這些後來人卻居然連祖輩們的水平都超不過，確實可以自殺了。我坦白，我基本除了學校裡寫的那些垃圾代碼外，就沒再寫過HashMap，但是這並不妨礙我使用std::hash_map。同時，在使用hash_map時，我發現我跟同行交流更方便了。他們甚至不用問，“老李，你丫用的是什麼資料結構，什麼演算法？”他們一看hash_map，一看for_each，一看remove_if，都知道了，連注釋都不用。這樣的方便，這樣的優秀，這樣的完美的C＋＋標準庫，我們卻使用了，我們被異化了，我們中的很多人，居然會不懂雜湊表了，不懂圖論，不懂這個那個了，我們確實該死！非常該死！眾位前朝的遺老遺少們，全力地炮轟我們吧！

但，你看到半個世紀前的軟體業有現在這麼繁榮嗎？

將演算法和工程嚴格對立的做法，就如同把魚兒剝離了水缸一樣，除了說你清高，真的沒臉再誇你什麼了。會寫個graph庫，真的都不好意思問問你寫的graph庫比boost::graph強到哪裡？效率高了？擴充性強了？還是別的什嗎？

沒錯，你可以詛咒我離開了boost和C++標準庫什麼都幹不了，雖然你指責的很無端很沒有道理，但我就假設你說的是真的，那我離開鍵盤和滑鼠還幹不了活了呢！這又怎麼說？！任何事物的發展，都是新事物立足在舊事物的屍體之上，沒有舊事物心甘情願的死亡，是不可能有新事物的誕生的。如果現在還是打孔穿孔的時代，還會有多少人去用電腦呢？如果現在還是5寸大餅的時代，還有多少人能用Windows、Office、Ubuntu呢？

然而，事實證明，舊事物並不是真的“死”了，而是以更加建設性的態度，參與了新事物的世界。C語言、x86彙編，死了嗎？沒死，因為作業系統的編碼還是需要他的。它沒有死，反而因為人少了而更加珍貴。傳統意義上的演算法，也是一樣，它不會死的，也會因為做的人越來越少，而越來越珍貴。少數人為多數人準備底層，多數人放棄包袱，更加關注自己的模組和功能。這就是世界，多層次，多極化，但卻能共同協作的世界。

傳統的演算法，我們當然應該瞭解，事實上，從高校出來的基本都有所瞭解。只是希望，切莫再有一個愚蠢的聲音告訴我們：“數學就是演算法，演算法就是一切……”。非也！你們所謂的演算法沒那麼高貴，該讓他走下神壇了，實際的、具體的、下裡巴的、形而下的工程和虛擬、抽象的、象牙塔的、形而上的傳統意義的演算法共同作用，才能構建好一個軟體的內涵和外延。

演算法離不開工程，就正如工程離不開演算法一樣，一兩個核心演算法的效率考慮，很可能關係到整個工程核心模組的結構組織，再松耦合的工程設計也不可能做到對邏輯的無關耦合。而在對這一兩個核心演算法進行考慮時，又往往離不開對相關專業的具體工具和API的熟悉和掌握。這就正如，從Direct3D的保留模式轉化到立即模式——調用的方法和習慣都變了，你怎麼保證演算法設計會一樣？又怎麼可能保證“松耦合”？也正如，農業軟體和遊戲軟體，工業流程軟體和企業流程軟體，適用的範圍不同，演算法的設計又怎麼可能相同？！

底層的工具、硬體結構和API決定了演算法，演算法關係著工程的核心結構，對工程的核心結構的設計也反過來影響演算法的實現。最終的結果就是互相作用共同補完，完成一個完整的解決方案。認為（所謂的）演算法高於工程結構，和認為工程結構高於演算法的想法，都太脫離實際了。因矛盾是對立統一的，或許對立，但最終的落腳點，卻必須是統一！

高校並不見得要培養出來一大堆能寫底層的人，因為那真的很沒有必要。還是應該根據人們的喜好，根據軟體行業所需要的真正的職位，更加細化這些職位的種類和具體職務，以期為各自安排好各自燦爛光輝的未來，這才是人民的園丁們和園丁組組長們應盡的職責。