摘要：年終總結(jié)結(jié)果到這個時間才寫，其實也是無奈。這一年最重要的事情就是順利從一只學(xué)生狗轉(zhuǎn)職為一只社畜。四月份畢業(yè)之后以前端工程師的職位入職天貓，到現(xiàn)在也差不多工作一年了。

年終總結(jié)結(jié)果到這個時間才寫，其實也是無奈。本來計劃過年寫的，沒想到Steam竟然開了個農(nóng)歷春節(jié)特惠，然后就被各種游戲打了，辣雞平臺，斂我錢財，頹我精神，耗我青春，害我單身

以下全都是個人看法，如果有不認同的地方，請大吼一聲“傻逼寫的啥”然后關(guān)閉頁面

本命年終于快過去了，不知道是不是因為沒有穿紅褲衩，這一年有很多不順心的事情，不過也有很多好事。這一年最重要的事情就是順利從一只學(xué)生狗轉(zhuǎn)職為一只社畜。四月份畢業(yè)之后以前端工程師的職位入職天貓，到現(xiàn)在也差不多工作一年了。這里寫一下干這行以來對于“前端”這個行業(yè)的看法和感悟。

前端工程師在校園里是一個復(fù)雜度和地位都被嚴重低估的職位。老師們對發(fā)展迅猛的前端技術(shù)不夠了解，更是有不少“師兄師姐”在介紹自己找工作經(jīng)驗時“xx天速成就找到一份前端工作”、“公司招聘前端也不問會什么，就問你肯不肯踏實干這行，肯干進去再教你”。當(dāng)然學(xué)校里的項目里也會有頁面，但由于老師和學(xué)生對前端各種技術(shù)的陌生，大多數(shù)都是使用jQuery堆積代碼完成功能了事。在大家眼里，寫頁面沒啥技術(shù)含量。

前端的很多基礎(chǔ)知識，都無法在學(xué)校學(xué)到。學(xué)校老師交給學(xué)生的大多都是基礎(chǔ)知識，比如算法、數(shù)據(jù)結(jié)構(gòu)、編譯原理、操作系統(tǒng)、計算機網(wǎng)絡(luò)這些，而針對于特定領(lǐng)域就很少涉及了。見過學(xué)校開設(shè)C、C++、Java、PHP等語言的課程，卻從來沒有看到過開設(shè)JavaScript、CSS、HTML的課程。網(wǎng)頁設(shè)計的選修課倒是有（我報了，很遺憾整個教室只有20人不到），但這里所謂的網(wǎng)頁設(shè)計并不是前端那一套技術(shù)棧，而是Dreamweaver使用入門。前端技術(shù)棧在校園里沒有普及。

就這樣產(chǎn)生了一個很有意思的現(xiàn)象：大堆公司喊缺前端，而學(xué)生們并不知道前端是什么，怎么去學(xué)習(xí)前端知識（最近兩年稍微好點了），他們更多的是去學(xué)Java、C++，走著師兄師姐們走過的道路。有幸現(xiàn)在已經(jīng)有百度這種大公司注意到了這點，到高校里開了不少前端知識講座，還在GitHub上搞了培訓(xùn)項目。

希望各個大公司的前端部門能夠更多的走進校園，給對前端感興趣的小朋友們一點指導(dǎo)。

去年上半年4月份入職打雜了一段時間之后，就開始學(xué)習(xí)React并且進行了一些實戰(zhàn)演練：

產(chǎn)出一篇文章輕松入門React和Webpack，意外的很受好評，segmentfault上超過了200的收藏，tmall的github博客上也有不少評論。可惜現(xiàn)在文章中已經(jīng)有很多不適用了，babel大版本到6發(fā)生了不少變化，本地調(diào)試也改成中間件了

把自己的博客lingyu.wang改成了全React實現(xiàn)，代碼在這里，用react-router做了個單頁面應(yīng)用，底層依然基于hexo，自己給hexo寫了個generate插件把所有數(shù)據(jù)生成json而不直接生成頁面，為了練手已經(jīng)喪心病狂了，SEO什么的完全不在乎

寫了一些腳手架和組件，亂七八糟參見玩具箱

由于負責(zé)天貓最復(fù)雜的前端應(yīng)用之一的開發(fā)和維護，有不少老代碼，也由于遷移成本太大沒有辦法在Java層上插入Node.js中間層，各種模塊之間各種耦合，中間也寫了篇用React做重構(gòu)時的一些思考。當(dāng)時項目里存在以下幾種耦合：

最蛋疼的就是壓根就沒有模塊化，所有代碼都在一個文件里，2k+行的jQuery那種。最老式的寫法，也是在學(xué)校項目里看到最多的方式，選擇器拿到DOM然后操作綁事件，大多多年前的代碼或者是后端兼職寫的。基本上沒有可維護性。解決這種基本上就靠推倒重寫了，考慮投入產(chǎn)出比看懂它的成本還不如重新寫一個來得快

稍微好一點的是增加了模塊化，但模塊內(nèi)部和之前思路沒什么區(qū)別，只是把上面那種代碼分開多個文件放了。不同的模塊在模塊內(nèi)部操作相同的HTML，一旦其中一個模塊改變了HTML結(jié)構(gòu)，其他模塊直接就bug了...

再好一點增加了前端模板引擎，各個模塊都在內(nèi)部使用模板引擎渲染自己的HTML，模塊初始化傳入一個容器，只要容器不沖突，模塊之間就不會基于HTML耦合。模塊會暴露一些接口，通過模塊管理器獲取實例相互之間直接相互調(diào)用，這樣依舊是強依賴，兩個模塊互相依賴，一旦其中一個換了，接口變了，另外一個模塊也需要改變自己的代碼。

模塊內(nèi)部完全黑盒，只要一個容器，里面的內(nèi)容由模塊自己控制。模塊有數(shù)據(jù)的入口和出口，入口就是一些由父模塊或頁面?zhèn)魅氲呐渲茫隹趧t是一些由父模塊或頁面?zhèn)魅肽K回調(diào)函數(shù)，回調(diào)函數(shù)里面附帶傳出的數(shù)據(jù)，而HTML相互之間無法互相修改，改了就報錯。沒錯這就是React

最后重構(gòu)的方案定下來是React+AMD+Gulp（你沒有看錯，沒有打包，沒有webpack），之所以不打包主要是有老代碼，組件頁都沒發(fā)布到npm上，而且由于阿里的CDN支持combo，所以也就不做打包了，至于使用React做重構(gòu)，主要是由于以下幾個原因：

使用React實現(xiàn)的模塊和組件完全黑盒，Web Component理念，標簽使用方便快捷。不會引入新的維護成本

組件容易抽離，形成沉淀。我曾經(jīng)把一部分新業(yè)務(wù)使用React實現(xiàn)，其中的不少組件稍加完善就沉淀出一些基礎(chǔ)組件，沒有剝離成本

模塊相互之間不會污染，沒辦法直接修改其他模塊的DOM，改了就報錯，然后QA就提著刀殺過來了

商家應(yīng)用，允許全異步，富交互功能型頁面，性能不太爛都能接受

目前新業(yè)務(wù)已經(jīng)完全基于React開發(fā)，組件庫也基本上沉淀出來了，而老業(yè)務(wù)也在通過一次次需求像React遷移

個人比較傾向于完全區(qū)分模塊和組件這兩個概念。組件是完全沒有業(yè)務(wù)邏輯的功能單元，比如下拉框啊、日期選擇啊這種，組件只專注自身的功能。組件可能會有嵌套，但當(dāng)發(fā)生了嵌套時，對外就是一個組件，父組件內(nèi)部的子組件對外將完全不可見，它的行為也將完全由父組件控制。組件是復(fù)用的單元，應(yīng)當(dāng)更多的形成沉淀。而模塊則包含業(yè)務(wù)邏輯，同時模塊還承載了一個比較重要的功能：和其他模塊通信。

所以大體上一個應(yīng)用就是：應(yīng)用被劃分為多個業(yè)務(wù)模塊，這些模塊邏輯上是扁平的，他們采用統(tǒng)一的通信機制進行通信，一個模塊上的數(shù)據(jù)發(fā)生變更時，會通知一個全局的通信中心，采用pub-sub機制將數(shù)據(jù)遞交給其他模塊，其他模塊拿到數(shù)據(jù)后影響自己的渲染。模塊內(nèi)部使用了很多的組件，但模塊內(nèi)部所有渲染使用的數(shù)據(jù)都由模塊直接進行管控，樹形傳遞給各個組件。可以這么想，模塊內(nèi)部類似Redux實例，而頁面上有多個Redux實例，它們再通過一個統(tǒng)一的pub-sub中心進行通信。為什么不整個應(yīng)用直接做一個Redux實例呢？主要是因為要考慮到跨BU合作和新老多種技術(shù)兼容。模塊內(nèi)部想怎么玩怎么玩，可以是React實現(xiàn)，可以使Vue實現(xiàn)，可以是原生js實現(xiàn)。模塊作為一個通信單元只要符合統(tǒng)一pub-sub通信接口即可。

這套理念也確實實現(xiàn)并且落地到了不少頁面中，但這樣玩顯然還不夠過癮。React終究是前端在玩，前端寫React組件、模塊和頁面很爽，但是數(shù)量大了一樣要加班一樣爽不起來。這里就在考慮有沒有可能降低門檻，把事情交給別人來做，比如后端。首先組件肯定是前端來寫了，沒多少后端能寫好前端組件的，如果能寫好，他就不是后端而是全棧了，這種人就應(yīng)該果斷拉過來干前端堵缺口。那么有沒有可能把模塊和頁面交給他們來寫，而前端只提供一些組件呢？

讓后端寫，最重要的一點就是給模板賦能，畢竟后端只能接觸到模板。這么一想，這不特么就是React和MVVM相結(jié)合么，把React的Virtual DOM或者說JSX標簽和MVVM的DOM模板一樣寫到HTML上，多么Web Component化啊。這里說一下為什么不直接用MVVM比如Vue，而是用React。MVVM確實對后端開發(fā)工程師很友好，但這些組件是我們平常開發(fā)前端應(yīng)用（前端部分前端自己負責(zé)的復(fù)雜業(yè)務(wù)）時沉淀下來的，這么一大批組件讓我們再去重寫一份MVVM的太蛋疼了，后期維護兩份也比較吃力。就這樣開始嘗試，經(jīng)過一段時間調(diào)研后，發(fā)現(xiàn)react-templates，可以把模板字符串轉(zhuǎn)化為React.createElement，當(dāng)時用browserify給它打了一個包，尼瑪壓縮后好像有500K+（未gzip），它是針對Node.js的。于是乎把它整個代碼大體上進行了重寫，移除了lodash，自己重寫了使用的一些工具方法，然后又重寫了模板解析部分，采用瀏覽器的XML解析器，又移除了esprima等語法校驗，然后又加了一堆定制化，最后壓縮后20K左右（未gzip），終于可以在頁面上用了...最后大體上就實現(xiàn)了一套這樣的方案：

一堆日常沉淀的React組件

一個全局的pub-sub通信工具負責(zé)模塊的通信

一個React實現(xiàn)的Module負責(zé)充當(dāng)模塊的角色

Module內(nèi)部使用React Templates字符串模板編譯成Virtual DOM的函數(shù)來進行渲染，可以通過一些“控制指令”來控制渲染結(jié)果，組件上面可以通過一些“通信指令”來遞交組件的數(shù)據(jù)給Module這個模塊。而Module模塊數(shù)據(jù)發(fā)生變更后會觸發(fā)整個模塊重繪，數(shù)據(jù)又會重新傳遞下來給組件并變更組件的渲染結(jié)果。

Module外部則是通過全局的pub-sub通信工具來負責(zé)模塊通信，Module負責(zé)與這個通信工具進行直接交互來進行數(shù)據(jù)通信。通信建立橋接的方式也是在Module上定義一些“通信指令”

最后，整個系統(tǒng)都采用React Templates來實現(xiàn)，整個頁面實現(xiàn)和通信全部寫在模板上，頁面上只有一堆組件（可以在模板里動態(tài)require，模板會在編譯期提取然后拉取完成了才進行初始化）。沒有任何業(yè)務(wù)js邏輯存在。

這樣實現(xiàn)了好幾個頁面我已經(jīng)成功上線跑了幾個月了，還有幾個正在實現(xiàn)中，看上去很美好。但后來還是發(fā)現(xiàn)了一些問題：模塊通信過程太復(fù)雜，一個完整的數(shù)據(jù)流轉(zhuǎn)過程通過指令很難很直觀的展現(xiàn)，一個看起來很簡單的交互中間可能會經(jīng)過4-5步數(shù)據(jù)流轉(zhuǎn)，甚至包括一些alert、confirm等等，想讓后端寫不太可能，連其他前端都看不太懂?dāng)?shù)據(jù)如何流轉(zhuǎn)。這一塊還有太多可以優(yōu)化的地方。

去年下半年我參與了部門統(tǒng)一使用的前端流程自動化工具的維護及改造，同時負責(zé)了商家端通用組件的腳手架的開發(fā)和維護。花了不少時間在前端流程自動化上。前端經(jīng)過這么多年的發(fā)展，頁面上承載的交互、功能、邏輯不斷增加，項目逐漸變得龐大，維護和開發(fā)成本也隨之增加，但依然招不到人。__這里順帶打個廣告，如果想來天貓前端的請發(fā)郵件至lingyucoder@gmail.com__。流程自動化也就愈發(fā)重要。最理想的狀況就是，只要是機械能夠完成的工作，人就不要參與了。用一些腳本代替簡單重復(fù)的勞動，這樣我們也就可以少加點班了。

Node.js給前端開發(fā)流程自動化帶來了福音。從目前部門前端開發(fā)流程來看，主要就是以下幾個步驟，括號里是對應(yīng)的開源工具：

創(chuàng)建項目（Yeoman）

構(gòu)建以及監(jiān)聽文件變化自動構(gòu)建（Gulp、Webpack、Grunt，Grunt估計現(xiàn)在用的很少了）

本地調(diào)試，資源代理（Koa、Express+各種定制的中間件）

自動化測試、代碼覆蓋率測試（mocha、istanbul、should/chai/expect、phntomjs、karma）

文檔自動化生成（自己基于AST提取，或者直接用jsdoc之類的工具）

自動化校驗、發(fā)布（一些腳本）

這里主要聊聊構(gòu)建、本地調(diào)試和自動化測試

現(xiàn)在的構(gòu)建過程已經(jīng)不再像以前那樣壓縮一下就簡單，構(gòu)建過程中往往會拿代碼生成語法樹然后做各種操作：

Babel爽爽寫ES6甚至ES7

將代碼中的注釋轉(zhuǎn)化為監(jiān)控打點（istanbul我記得就是基于語法樹給每個語法分支包一層打點層，匯總數(shù)據(jù)）

將代碼中的注釋提取生成文檔（React組件自動生成props文檔就是這種方式）

將commonjs規(guī)范的代碼轉(zhuǎn)化為各種各樣的模塊化解決方案（AMD、KMD、UMD等等）

提取模塊間的依賴關(guān)系，梳理應(yīng)用模塊依賴關(guān)系，繪制模塊依賴樹

Webpack打包

各種語法檢查（eslint，jshint），有時候還會有一些定制化的校驗

...

現(xiàn)在大家都比較中意webpack，依賴打包使得資源請求數(shù)大幅度減少（使用不支持combo的CDN服務(wù)的公司肯定很開心）。我個人還是對于webpack有一些顧慮，主要有兩點

不太贊同瀏覽器內(nèi)使用的資源也發(fā)布到npm上。瀏覽器上和Node.js通用的代碼可能也就不到5%（lodash啊，underscore啊，moment啊這種），在npm上找到一個模塊還要確認到底哪個場景下可用。使用的即便是這些可以共用的庫，也會有一個很蛋疼的問題：Node.js的模塊往往大而全實現(xiàn)盡可能多的功能，而頁面使用的模塊則是盡可能小而美，資源加載量盡可能少。比如只用到時間格式化和反格式化就引入一整個moment（moment真特么大，我一般就格式化反格式化，喜歡用fecha），對于Node.js也許沒什么壓力，但對于頁面就很蛋疼了。現(xiàn)在rollup試圖解決這個問題，還是比較值得看好的

不同版本重復(fù)打包的問題。這個問題比較頭疼。如果一個項目依賴了兩個組件，而這兩個組件引用了一個庫的兩個不同版本，這個庫就會被打包兩份，于是乎代碼量就duang一下增大了。目前依舊沒有看到比較好的方式來解決。雖然可以用peerDependencies對一些基礎(chǔ)庫（比如React這種）做一下處理，也只是緩解一些罷了。

另外吐槽一句，webpack配置真繁瑣啊，個人目前傾向的方案是使用webpack+gulp，webpack負責(zé)打包和構(gòu)建，其他的工作依舊交給gulp，我喜歡stream（不是steam）

前端資源本地調(diào)試其實挺簡單的，就是把線上使用的資源代理到本地資源。由于現(xiàn)在一般都會使用CDN來承載這些資源（如果你們公司不用CDN，請找你們老板撥點經(jīng)費買個CDN服務(wù)吧），大致上也就是幾個步驟：

把CDN的域名通過host指向本地

在本地80（HTTP）或443（HTTPS）端口開啟對應(yīng)的代理服務(wù)，根據(jù)請求查找本地資源返回

如果涉及需要開啟多個服務(wù)，將各個服務(wù)開在不同的端口后在80或443端口加個nginx層做轉(zhuǎn)發(fā)

目前部門里面用的是Koa+中間件實現(xiàn)了這里面所有的內(nèi)容。Koa現(xiàn)在也2.0了，使用新版本的Promise的co，用起來還是很爽的

如果一旦涉及到本地模板的調(diào)試，就很蛋疼了，基本上是模擬數(shù)據(jù)，這里懶得扯了。

對于自動化測試這一塊，在學(xué)生時代一直覺得測試麻煩，沒啥收益。但實際上自動化測試對于開發(fā)效率提升很大。之前參與部門統(tǒng)一構(gòu)建工具的改造，有任何修改就跑一遍測試用例和代碼覆蓋率，效率非常高，還非常容易形成沉淀，一旦有bug，就把bug會發(fā)生的場景也做成一個測試用例，方便后人接手。而且把代碼接入像travis這樣的持續(xù)集成平臺后，代碼質(zhì)量更有保證了，任何一次push都會自動觸發(fā)測試，即便是pull request里的代碼也可以保證質(zhì)量。現(xiàn)在寫代碼覆蓋率低于90%就覺得各種不爽，一定要提到90%以上。

對于Node.js的模塊，測試很方便，除了命令行工具可能需要加像sinon這樣的模塊來監(jiān)聽stdio以外，其他的基本上都能直接在代碼中模擬環(huán)境。由于個人寫Node.js代碼喜歡拆分的很細，每個邏輯單元都用co、curry做包裝，所以特別喜歡使用mocha+should，should 8.0+直接支持Promise，爽歪歪，

對于瀏覽器里跑的代碼，測試和覆蓋率就比較麻煩了，首先模擬環(huán)境比較蛋疼，大致上3種方案：

構(gòu)建一個測試頁面，人肉直接到虛擬機上開各種瀏覽器跑測試頁面（比如f2etest），這個問題就是不好持續(xù)化集成，人肉工作較多

使用phantomjs構(gòu)建一個偽造的瀏覽器跑單元測試，大致上就是先用gulp-istanbul給代碼打點，然后拿mocha-phantomjs跑包含測試用例的頁面，最后通過hook拿到結(jié)果用istanbul生成可視化的覆蓋率頁面，蛋疼就是phantomjs畢竟是Qt的webkit，不是真實環(huán)境，phantomjs也是各種坑

通過karma調(diào)用本機各種瀏覽器進行測試，這個現(xiàn)在還沒玩的很6，還在研究中。還是有不少問題沒解決，畢竟用的mac，去哪兒找IE 8，囧，更別說移動端那么多機型

對于測試個人一直堅持一個觀點：基于投入產(chǎn)出比來做測試。由于維護測試用例也是一大筆開銷（畢竟沒有多少測試會專門幫前端寫業(yè)務(wù)測試用例，而前端使用的流程自動化工具更是沒有測試參與了）對于像基礎(chǔ)組件啊，基礎(chǔ)模型啊之類的不常變更且復(fù)用較多的部分，可以考慮去寫測試用例來保證質(zhì)量，但對于迭代較快的業(yè)務(wù)邏輯以及生存時間不長的活動頁面之類的就別花時間寫測試用例了，維護測試用例的時間大了去了，不如喝杯茶冷靜下讓QA他們?nèi)y吧。

這一年由于轉(zhuǎn)職社畜各種忙的要死，導(dǎo)致沒有多少時間靜下心來看書了，文章也寫得少了。于是更傾向于每天水一水我的github（中間一大段空白因為3DS到貨了，鏖戰(zhàn)怪物獵人4G，這游戲真特么好玩），寫一些腳手架啊、組件啊、小工具啊啥的。之前覺得一些開源的logger不好用，就自己寫了個linglog，之前負責(zé)一個業(yè)務(wù)變更比較多總是打tag發(fā)布，就寫了個自動發(fā)布程序publishy，它會在發(fā)布前做一些校驗防止我沒有commit或者沒有add之類的。還有像React組件自動化提取props做文檔弄了個react-prop-table，以及對應(yīng)的配套的markdown內(nèi)容段自動更新gulp插件gulp-insert-md。對應(yīng)還有一些less依賴關(guān)系解析啥的弄了less-tree，然后有個需求要在模塊更新時自動輸出最新更新有哪些變動于是有了changelogy，然后還有幾個自己弄得帶單元測試、代碼覆蓋率測試、travis持續(xù)集成、eslint等的腳手架：React組件腳手架generator-lingyu-react-component, Node模塊腳手架generator-lingyu-node-modules, gulp插件腳手架generator-lingyu-gulp-plugin, 命令行工具腳手架generator-lingyu-cli-modules。寫這些玩意過程中學(xué)到了不少Node.js的姿勢，雖然離一個真正的Node.js工程師差的太遠

另外一點是入職后全面從sublime切到atom了，python苦手還是傷不起，咱用atom有插件需求找不到自己寫一個，比如之前給xtemplate模板寫了個atom語法高亮和snippet插件atom-language-xtpl，感覺比之前用sublime爽多了

還花了點錢買了SnippetsLab這個軟件，用來放一些代碼片段超好用，我在里面放了不少自己平常寫的一些小的工具函數(shù)，比如clone啊，unique啊，param和unparam啊這種，需要的時候就搜一下復(fù)制出來，方便快捷

今年玩的游戲不多，因為3DS到貨了，先說幾個3DS游戲：

怪物獵人，沉迷了一段時間，甚至一整天一整天的和各種龍做斗爭。現(xiàn)在怪物獵人累計游戲時間應(yīng)該有250小時了...

口袋妖怪X：硬著頭皮啃英文，擼寵系統(tǒng)好棒，每天擼一擼自己的寵，看到他們開心的樣子自己也開心。通了一周目就懶得啃英文了

牧場物語，在同事推薦下玩了，模擬經(jīng)營農(nóng)場，種菜、種果樹、養(yǎng)各種動物賣錢...玩了幾十個小時吧，玩不下去了...后面每天刷牛擠牛奶，擼雞一天就結(jié)束了...沒領(lǐng)悟到游戲的樂趣

路易吉鬼屋，超級瑪麗里的弟弟被拉到鬼屋里探險的故事，樂趣就是看路易吉這個大寫的慫貨被各種鬼嚇尿...解密游戲，其實挺好玩的

馬里奧賽車：和跑跑道具賽差不多，玩道具賽，道具比較少，賽道也少，難度也低。

勇氣默示錄：回合制RPG，還在龜速通關(guān)中，畫面很棒，3D的人物很Q，相當(dāng)不錯的游戲

然后說一些PC的：

俠客風(fēng)云傳：情懷！絕對的情懷！作為一個當(dāng)年武林群俠傳的狂熱愛好者，俠客風(fēng)云傳我通關(guān)了至少6次，乞丐、東廠、盟主、霸圖、天王各種都通了一遍。湘云還是一如既往的女神，希望徐大早日重制金庸群俠傳

仙6：這個戰(zhàn)斗系統(tǒng)特么什么鬼...沒有玩下去的動力啊

堡壘（bastion）：很精致的游戲，畫面唯美，歌曲好聽，劇情不長但很好玩。

進化之地2（evoland2）：尼瑪一個游戲能這么玩我算是長見識了，集DQ、塞爾達傳說、超級瑪麗、拳皇、雙截龍、炸彈人、游戲王、洛克人、1943等等于一身的游戲也沒誰了

阿瑪拉王國：和老滾有點像，不過比老滾有打擊感，重要的是有WOW那種裝備系統(tǒng)。老滾的裝備系統(tǒng)是個鬼...可惜沒有老滾那么多mod，畢竟少女卷軸

饑荒：這游戲太特么難了，一到冬天就死...得找個大神帶我

春節(jié)剁手買了昆特牌3和龍騰世紀，有時間玩一玩。最后重申一句：辣雞平臺，斂我錢財，頹我精神，耗我青春，害我單身

看他們的總結(jié)都有這個，于是我加上了

光棍年數(shù)++

前端發(fā)展太快，要學(xué)的太多。本來去年計劃學(xué)React Native的，結(jié)果只寫了個Demo...Electron也是只跑了個HelloWorld...Node.js的服務(wù)器也只是搭了個簡單的...canvas也是只寫了一些小Demo。希望新的一年技術(shù)不掉隊，能夠多學(xué)點這些之前想學(xué)沒學(xué)的東西。另外希望能夠沉淀出自己的組件庫，以后快速搭建一個頁面也方便一些