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

年終總結(jié)結(jié)果到這個(gè)時(shí)間才寫(xiě)，其實(shí)也是無(wú)奈。本來(lái)計(jì)劃過(guò)年寫(xiě)的，沒(méi)想到Steam竟然開(kāi)了個(gè)農(nóng)歷春節(jié)特惠，然后就被各種游戲打了，辣雞平臺(tái)，斂我錢(qián)財(cái)，頹我精神，耗我青春，害我單身

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

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

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

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

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

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

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

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

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

寫(xiě)了一些腳手架和組件，亂七八糟參見(jiàn)玩具箱

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

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

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

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

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

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

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

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

模塊相互之間不會(huì)污染，沒(méi)辦法直接修改其他模塊的DOM，改了就報(bào)錯(cuò)，然后QA就提著刀殺過(guò)來(lái)了

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

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

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

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

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

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

一堆日常沉淀的React組件

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

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

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

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

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

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

去年下半年我參與了部門(mén)統(tǒng)一使用的前端流程自動(dòng)化工具的維護(hù)及改造，同時(shí)負(fù)責(zé)了商家端通用組件的腳手架的開(kāi)發(fā)和維護(hù)?；瞬簧贂r(shí)間在前端流程自動(dòng)化上。前端經(jīng)過(guò)這么多年的發(fā)展，頁(yè)面上承載的交互、功能、邏輯不斷增加，項(xiàng)目逐漸變得龐大，維護(hù)和開(kāi)發(fā)成本也隨之增加，但依然招不到人。__這里順帶打個(gè)廣告，如果想來(lái)天貓前端的請(qǐng)發(fā)郵件至[email protected]__。流程自動(dòng)化也就愈發(fā)重要。最理想的狀況就是，只要是機(jī)械能夠完成的工作，人就不要參與了。用一些腳本代替簡(jiǎn)單重復(fù)的勞動(dòng)，這樣我們也就可以少加點(diǎn)班了。

Node.js給前端開(kāi)發(fā)流程自動(dòng)化帶來(lái)了福音。從目前部門(mén)前端開(kāi)發(fā)流程來(lái)看，主要就是以下幾個(gè)步驟，括號(hào)里是對(duì)應(yīng)的開(kāi)源工具：

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

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

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

自動(dòng)化測(cè)試、代碼覆蓋率測(cè)試（mocha、istanbul、should/chai/expect、phntomjs、karma）

文檔自動(dòng)化生成（自己基于AST提取，或者直接用jsdoc之類(lèi)的工具）

自動(dòng)化校驗(yàn)、發(fā)布（一些腳本）

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

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

Babel爽爽寫(xiě)ES6甚至ES7

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

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

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

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

Webpack打包

各種語(yǔ)法檢查（eslint，jshint），有時(shí)候還會(huì)有一些定制化的校驗(yàn)

...

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

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

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

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

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

把CDN的域名通過(guò)host指向本地

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

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

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

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

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

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

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

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

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

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

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

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

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

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

今年玩的游戲不多，因?yàn)?DS到貨了，先說(shuō)幾個(gè)3DS游戲：

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

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

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

路易吉鬼屋，超級(jí)瑪麗里的弟弟被拉到鬼屋里探險(xiǎn)的故事，樂(lè)趣就是看路易吉這個(gè)大寫(xiě)的慫貨被各種鬼嚇尿...解密游戲，其實(shí)挺好玩的

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

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

然后說(shuō)一些PC的：

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

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

堡壘（bastion）：很精致的游戲，畫(huà)面唯美，歌曲好聽(tīng)，劇情不長(zhǎng)但很好玩。

進(jìn)化之地2（evoland2）：尼瑪一個(gè)游戲能這么玩我算是長(zhǎng)見(jiàn)識(shí)了，集DQ、塞爾達(dá)傳說(shuō)、超級(jí)瑪麗、拳皇、雙截龍、炸彈人、游戲王、洛克人、1943等等于一身的游戲也沒(méi)誰(shuí)了

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

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

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

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

光棍年數(shù)++

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