《Lua設計與實現》的做者codedump：學習也要講究性價比

本文僅用於學習和交流目的，不得用於商業目的。非商業轉載請註明做譯者、出處，並保留本文的原始連接：http://www.ituring.com.cn/art...

導讀：

訪談以前，我曾屢次央求codedump給我一張照片，用於簡介部分的介紹。如他所願，無論是派人偷拍仍是全網開搜，我都沒有獲得也不可能找到一張照片。因此，就有了這樣一篇沒有嘉賓圖片的訪談文章。

我想，這大概就是技術型人才的「通病」吧。低調、務實、有乾貨！

不過，我仍是知道了codedump筆名掩蓋下的真身，他被Lua吸引的緣由，研究Lua的方法，Lua的優點以及Lua的編譯原理，等等。

好了，仍是大家本身開閱吧~

訪談嘉賓：

codedump，一線開發人員，長期從事互聯網後端服務的開發工做。

他曾經在網易等公司從事遊戲服務器後臺開發，由於工做須要，使用C++編寫服務核心引擎和使用Lua腳本編寫遊戲邏輯的技術組合，以後開始對Lua產生濃厚的興趣。他不斷地研究Lua的實現原理，而且陸續公佈在網絡上：www.codedump.info。

codedump多年的努力，最終以紙質圖書的形式——《Lua設計與實現》呈現給了你們。

訪談話題：

越想作好一件事，心理負擔就越大
接下這件事以後，個人心理負擔變得很大。若是成爲正式的出版物，讀者是要真金白銀地花錢來買的，我但願儘可能作好，不辜負別人的指望。

爲何使用codedump這個筆名？有什麼特殊的含義？

codedump是我本身造的單詞，實際上是code和dump這兩個單詞的組合。我很喜歡深刻到代碼層面去了解一些項目的運做原理，也就是把code給dump出來，因此就起了這個名字。老是會有人把它錯當作coredump，話說哪有程序員用這個名字咒本身的。（笑）

寫做《Lua設計與實現》的時候，最大的困難是什麼？

寫做過程當中，主要有兩方面的困難。

一方面是技術上的。最大的問題是，Lua解釋器解析Lua文件、生成Lua Opcode的過程當中，涉及一些編譯原理的知識。另外，Lua爲了效率實際上是一次遍歷的，也就是說，只分析一遍源文件就生成Opcode。雖然性能提高了不少，可是對於（當時基礎不太好的）我來講就有不小的困難。

這方面的分析文檔比較少，由於大部分Lua分析的文檔集中在虛擬機自己的結構和運做上，涉及Lua解釋器解析過程的文檔太少了。後來，我找到了調試分析的辦法，也就是像書裏分析的那樣：每分析一種類型的指令時，就以一段簡單的Lua來具體分析，同時把握住分析的幾個關鍵函數，如luaK_code和luaV_execute，慢慢地本身也就啃下來了。從個人角度來看，這部分的內容仍然不是很滿意。若是精力容許，我但願能夠繼續這方面的研究。

另外一方面的困難是心理上的。編輯王軍花看到了我在Github上公開的文檔，經過郵件找到我，但願把內容整理成書出版。等接下這件事以後，個人心理負擔變得很大。若是成爲正式的出版物，讀者是要真金白銀地花錢來買的，我但願儘可能作好，不辜負別人的指望。

越想作好一件事，心理負擔就越大。加上工做、家庭等因素，寫做會被打斷，從新撿起來又須要更多的時間和精力。由於以爲有些章節寫得不夠好，我一度有放棄此次出版計劃的打算，還好編輯王軍花有足夠的耐心，才把這個差點半途而廢的事情堅持作完了。

從最開始簡單地寫一些東西，到最後和出版社合做、和網上的朋友合做等，這些都是很好的經歷。

你認爲，書中哪部分最重要，爲何重要？

哪些部分「最重要」，其實還要看我的的需求。不過，我認爲，應該瞭解Lua棧和虛擬機的一些原理，好比代碼是如何先分析再到虛擬機中執行的，好比Opcode是如何組織在Lua棧中的。這部分的內容能夠在書中的第五章找到，由於明白了這些知識會對理解代碼的生成有幫助。

學習也要講究性價比
接觸Lua時，我發現Lua 5.1.4版本的代碼量只有不到兩萬行。對於一個世界級同時在業界大量使用的腳本語言，這樣的代碼量確實性價比過高。

爲何對Lua產生濃厚的興趣，談一談對Lua產生興趣的原因？

接觸Lua時，我發現Lua 5.1.4版本的代碼量只有不到兩萬行。對於一個世界級同時在業界大量使用的腳本語言，這樣的代碼量確實性價比過高。加上，我一直對如何實現一門語言很感興趣，因此就堅持着學習了下來。我發現Lua的代碼組織形式精幹簡潔，幾乎沒有冗餘。相比Nginx，我認爲Lua纔是最好的C語言項目。

另外，我在Lua身上看到了一種別樣的編程語言設計哲學。Lua歷來沒有追求過要作一門號稱「能夠解決全部問題」的語言，它對本身的定位就是輔助型的語言，這樣的出發點也決定了它的特色——小巧、性能高、可擴展性強。

跟Python、Ruby這樣的語言相比，Lua有哪些特色？更適合解決哪類的問題？

Python、Ruby的定位是全能型的語言，即它們能夠獨立完成一些工做。而Lua的定位是傳球者、助攻者，它須要藉助宿主語言，輔助宿主語言解決問題。

根據我以前從事網絡遊戲服務器開發的經驗來看，Lua更適合運用在既須要高性能又須要靈活性的狀況下。咱們能夠採用C、C++這樣的編譯型語言實現核心的模塊，如網絡、數據庫操做等，同時提供接口給Lua層進行調用，在須要靈活實現的業務層用Lua代碼來實現。

討論Lua解決技術問題的時候，你想到的、最佳的實際例子是什麼？

OpenResty，這個項目在章亦春（網名agentzh，OpenResty項目的發起人）的帶領下，已經取得了巨大的成功。它的架構正是我前面提到的：使用高性能的編譯型語言實現底層，同時給業務編寫提供Lua接口。通過這些年的發展，OpenResty已經愈來愈像一個平臺化的軟件，開發人員不須要本身寫底層的C代碼，使用Nginx配置文件和Lua腳本就能驅動Nginx來完成業務。

另外，OpenResty把Lua的協程很好地使用了起來，以同步的方式來寫業務代碼，避免了異步回調的問題。作太高併發服務器的人都知道，事件驅動加異步回調是經常使用的手段，可是回調層次多了，又會讓代碼邏輯變得支離破碎，這些痛點就是協程類技術最好的發揮場所了。固然，這很大方面也得益於Lua的精簡和高效。試想若是根據OpenResty的設計，每一個連接就建立一個對應的Lua協程，那成本是很大的。

除了遊戲、擴展數據庫插件等方面，Lua適合開發Web應用嗎？

前面提到的OpenResty就是基於Web服務器的例子。可是，好像如今尚未看到很流行的Web框架是使用Lua編寫的。

簡單介紹下Lua的編譯原理？

Lua使用最簡單的遞歸降低的分析方式，只須要掃描一遍Lua源文件，就生成Lua虛擬機執行所用的OpCode。原理自己並不難，只要可以清楚一些編譯前端的知識就能夠閱讀Lua源碼了，只是因爲Lua對性能的追求，因此代碼寫得很精簡，須要結合具體代碼的生成過程去理解。我在生成代碼那一章也是這樣，一個一個例子逐漸展開來分析這一過程的。

回頭看你本身學習Lua的這一段歷程，哪部分是最耗費精力的？

其實，前面已經提到了，Lua分析代碼生成Opcode的過程是最耗費精力的。GC部分也是難度比較大的，可是由於雲風寫的關於「Lua GC分析」的系列文章，難度會相對減小不少。

平民化的資本，構建出龐大的網絡世界
編程跟數學的特色很像，只須要有一臺能夠編程的電腦就能構建起虛擬的世界。它對場地設備的要求也還算比較平民化，更多的是須要抽象和邏輯思惟能力，這對我而言是相對簡單的。

據說你並不是科班出身，爲何會選擇進入編程這一行？

雖然我讀的是理科，可是對於須要本身動手作實驗的學科，如化學、物理，卻並不擅長。像數學這樣的只須要紙和筆就能完成的科目，我學得還不錯。編程跟數學的特色很像，只須要有一臺能夠編程的電腦就能構建起虛擬的世界。它對場地設備的要求也還算比較平民化，更多的是須要抽象和邏輯思惟能力，這對我而言是相對簡單的。

DOOM之父卡馬克有一個相似的說法，「在信息時代，進入編程領域的壁壘徹底不存在了。即便有也是自我強加的。若是你想着手去開發一些全新的東西，不須要數百萬美圓的資本。你只須要足夠的比薩和健怡可樂存在冰箱裏，有一臺便宜的PC用於工做，以及讓你堅持下來的奉獻精神。」

若是不能走得比別人快，那就儘可能走得比別人遠一點、長一點
實際上，不少開發人員遇到的，好比中年危機，好比面對新知識的焦慮，等等，我也有同樣的困惑。目前能想到的很少，只是肯定本身是喜歡技術的，願意一直在技術的道路上走下去的。

你平時很喜歡寫做，記錄技術學習的點滴。寫做是你的技術學習方法嗎？

最開始寫博客記錄技術學習的時候，是想在整理思路的前提下，可以和其餘同行分享一些知識。若是能把一個知識點用簡潔清晰的語言寫出來，讓別人看懂，才能說明個人理解很到位。

寫技術類文章的時候，我建議首先把原理和問題解釋清楚，而後才解釋具體的數據結構和僞代碼的算法，最後纔是具體的代碼。我不建議大量地貼代碼，由於可能當時你懂了，等過段時間後你就不懂了。決定寫Lua源碼分析的文章，我也是堅持這個初衷和方式。最開始的時候，我並無想到能以紙書的形式呈現，回過頭來看，之前作過的積累纔是最重要的。

技術學習的過程當中，最重要的三點是什麼？

首先仍是得有興趣吧，沒有興趣的話，事情作起來彆扭。其次是善於概括和總結知識，寫博客、技術文章，嘗試向別人解釋清楚一個知識點，時常整理知識點，跟之前學過的東西串聯起來。最後應該就是不斷提升本身解決問題的思路、能力等。出現了問題不是大事，問題是出了問題以後本身可否解決、可否從裏面學到東西。

你對本身將來的技術之路，是怎麼規劃的？

這個問題太大了，實在回答不了太多。實際上，不少開發人員遇到的，好比中年危機，好比面對新知識的焦慮，等等，我也有同樣的困惑。目前能想到的很少，只是肯定本身是喜歡技術的，願意一直在技術的道路上走下去的。而後找對適合本身的技術方向，走好眼前的路吧。

若是不能走得比別人快，那就儘可能走得比別人遠一點、長一點吧。固然，作到這些的大前提，仍是身心的健康。

---

更多精彩，加入圖靈訪談微信！