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

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

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

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

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

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

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

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

去年上半年4月份入職打雜了一段時間之后，就開始學習React并且進行了一些實戰演練：

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

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

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

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

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

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

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

模塊內部完全黑盒，只要一個容器，里面的內容由模塊自己控制。模塊有數據的入口和出口，入口就是一些由父模塊或頁面傳入的配置，出口則是一些由父模塊或頁面傳入模塊回調函數，回調函數里面附帶傳出的數據，而HTML相互之間無法互相修改，改了就報錯。沒錯這就是React

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

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

組件容易抽離，形成沉淀。我曾經把一部分新業務使用React實現，其中的不少組件稍加完善就沉淀出一些基礎組件，沒有剝離成本

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

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

目前新業務已經完全基于React開發，組件庫也基本上沉淀出來了，而老業務也在通過一次次需求像React遷移

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

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

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

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

一堆日常沉淀的React組件

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

一個React實現的Module負責充當模塊的角色

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

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

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

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

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

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

創建項目（Yeoman）

構建以及監聽文件變化自動構建（Gulp、Webpack、Grunt，Grunt估計現在用的很少了）

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

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

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

自動化校驗、發布（一些腳本）

這里主要聊聊構建、本地調試和自動化測試

現在的構建過程已經不再像以前那樣壓縮一下就簡單，構建過程中往往會拿代碼生成語法樹然后做各種操作：

Babel爽爽寫ES6甚至ES7

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

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

將commonjs規范的代碼轉化為各種各樣的模塊化解決方案（AMD、KMD、UMD等等）

提取模塊間的依賴關系，梳理應用模塊依賴關系，繪制模塊依賴樹

Webpack打包

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

...

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

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

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

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

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

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

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

如果涉及需要開啟多個服務，將各個服務開在不同的端口后在80或443端口加個nginx層做轉發

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

然后說一些PC的：

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

仙6：這個戰斗系統特么什么鬼...沒有玩下去的動力啊

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

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

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

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

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

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

光棍年數++

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