爲何lua能有本身的生命

爲何lua能有本身的生命？

最近又心血來潮，想學lua,公司對新技術很渴望，但本身做爲一名程序員，心裏卻很是保守，由於本身貌似只對圖形,html,flash還有一些非主流的遊戲技術十分感興趣。lua是做爲遊戲中大量使用的腳本。可是如今不少人都用腳原本完成輕量級開發，本身就將就看了下。接下啦還須要有耐心把他作完。

    來到魯班公司後，發現一些問題：

1.             代碼陳舊，be這種還要維護好幾年前的c++代碼。
2.             代碼複雜一層嵌一層
3.             莫名其妙的需求，改這裏改那裏的。                                                                     最有感觸的是去年下半年搞砸的那個mc，關於行匹配和列匹配那個算法寫起來很麻煩，固然對於藉口封裝的原則，只須要把算法接口提供出來便可，可是當時的代碼很亂，很容易須要重構。後來又提出匹配算法的模糊匹配和行匹配。還有就是測試一直找麻煩的界面問題。
4.             還有就是一堆bug，改完以後，發現總差那麼一點點。而後測試人員須要複測，要從服務器拿版本。固然版本初期不明顯，到快要發版的時候問題來了，服務器會按時間編譯版本，可是你解決好這個問題版本剛準備開始作，平白無故，又拖了好長時間，只能等到下一次作版本的時候才能出來。
5.             還有就是界面問題，須要該來改去的。
6.             webservice這一塊，用手封裝代碼很麻煩，林工搞了一個webservice工具（代碼模板實現的），雖然很好用，但中間環節莫名其妙的出了一些問題，旁人有時很難解決，還有就是接口改動也不太容易。
7.             c++編程水平的提高是一個漫長的路。

針對以上的這些問題，我以爲用腳本能夠輕易的解決。

1.         對於界面問題：（分爲佈局和界面控件的刷新問題）使用lua，若是有產品或者ui等不滿意，能夠實時調整。
2.         關於針對改bug，以及需求改動，服務器作版本的速度加快，並且這個東西相似於配置文件，本身直接發給測試去測試，若是bug解決，直接提交服務器，服務器是不用編譯這個東西的。
3.          webservice，這個公司有想把藉口變爲http的rest的傾向，可是lua和python相似，提供了webservice和http的方式。並且這個也恰巧是c++的短板
4.          lua能夠輕易的與c++交互。換句話說，c++和lua是關係最好的一對朋友
5.          一些配置文件用lua讀取，更方便，如json,xml等。（沒辦法，不耗費資源的東西，工做量不大，可是簡潔的開發，這方面腳本語言頗有優點）

          固然lua也不是萬能的，一些問題要注意，lua運算效率很高，可是要比c++差，lua寫界面也不容易。lua適合幹一些輕量級的事情。

           還有一些東西好比:qq郵箱協議，http協議，文件上傳,下載等,能夠用lua來搞一套，也輕鬆方便許多，使用lua就是這麼方便。

          還有在魯班這一年也不是什麼進步都沒有，本身喜歡的東西仍是要堅持，工做也要堅持，二者能統一也是最好的選擇，後面本身會在luban 的pdsframework的基礎上搭建一個LuaFrameWork For Pds來證實本身的猜測。固然啦，看了manager和cmd模式以及後來co的框架實現（反射機制來實現manager的註冊），使我有自信，只須要輕量級的改動便可支持lua的嵌入。

           

初步設想

         目前的想法，針對webservice,rest(http)，作一個封裝，針對manager/cmd作一個封裝，而後順便對於全局使用的，即隨時調用和c++的通訊的特殊lua類便可。這麼作的前提是保證lua的引入是增長其靈活性的，而不打擾原有的開發，也就是說在實際功能作業務的時候，咱們能夠多一種選擇，假如我這一塊用c++作很麻煩，我就用腳本，固然用c++也得保證原有基礎開發的不改變。

 

       還有一句話送給本身:堅持，毅力是人生事業開拓的真諦

                                                                                                                                    ~洋