2016年工作中做過最自豪的兩件事情：
- 把 Vue.js 和 Webpack 技術棧引進公司並逐步成為前端規範；
- 開源 iView 專案。
初識 Vue
第一次接觸
使用 Vue.js 已經有一年半時間了，在接觸 Vue 之前，有寫過半年多的 Angular，所以剛瞭解 Vue 時，與很多開發者一樣，認為 Vue 是一個輕量級的或是移動端的 ng，就好比 zepto 之於 jQuery。直到 15 年 10 月，打算用 Vue 開發一個個人專案時，才開始認真地學習它，發現 Vue 的使用方法和 API 設計如此優美簡潔，而且中文文件甚是詳細，我覺得這也是 Vue 受很多中國開發者喜愛的原因，許多初中級開發者、英文不好的、jQ導向的，在剛接觸 MVVM 時，這點很有價值，再者 Vue 的使用和學習門檻相比 ng 和 React 的要求都要低，概念理解起來也容易。
比起 Angular，Vue 最大的特點就是對資料雙向繫結這件事處理的很優雅。ng 中你需要注入依賴服務，比如 $scope 和 $rootScope，變數寫起來也散落在各處，而且有時候還得用 $apply 來告知，這對於很多初學者來說是很麻煩的事情。我以前是寫 jQuery 的，所以還是喜歡用 jQ 的很多東西，比如 ajax，而 Vue 在資料使用上很靈活，可以引用外部變數，可以在各種情況下直接修改，不需要額外的工作，所以當看到 Vue 雙向繫結這一特性時，就決定嘗試用它了。
一個人搞了一個產品
從 14 年畢業到 15 年底，就一直在兩個規模不大的創業團隊工作，先後做了 5 款產品，都是 App，涉及的面也很廣，比如 Canvas、Hybrid 什麼的。在初創團隊工作就像打了雞血一樣，每天早上起床都迫不及待地開始寫程式碼，對工作的熱愛絕對不是隻把它當做一件賺錢的事情，所有人都是有理想和技術追求的，所以那段時間我做的東西都很用心、精緻。
兩年的創業經歷也把我鍛鍊成了一個對產品有理解、追求細節、美觀的一個人。
從 15 年中旬開始，由於專案需要，我開始接觸 Python，這也是我第一次接觸後端語言，以前對服務端的開發是一點不懂的。不知道是 Python 本身的原因，還是我理解的快，上手其實並不難，而且沒多久就已經可以熟練的寫起來了（現在接觸的東西多了，覺得那時學習的快，是有一套很好的架構和有人帶，先能寫，然後慢慢了解其中奧妙，這種辦法對於程式設計師掌握一門新技術還是很有效的）。
我相信但凡寫過 Python 的人，都會用優雅來形容它，比如一行程式碼帶有迴圈的賦值：
user_hash = dict((str(user.id), user.to_base_dict()) for user in users)複製程式碼其實寫後端和寫前端，很多地方是想通的，只是概念上有區別。只不過後端專注在資料的獲取、快取和整理上，加以各種服務，前端則在獲取資料、整理資料、視覺化資料。
學會了 Python，發現這個時候可以自己獨立做一點東西了，於是就有了 一個人搞了一個產品 。不賣關子了，這個產品就是 TalkingCoder，從產品、設計、前端、後端、運維、iOS & Android 客戶端，幾乎都是我一人擼的了，只不過在寫移動 App 時，有兩位兄弟幫忙寫了個殼。
從產品和技術複雜度上，TalkingCoder 很接近 知乎 和 Segmentfault，基於關注內容推薦的 Feed 流、文章、提問（最佳實踐）。看一下用到的技術棧：
後端當然是基於 Python 了，主要用 Tornado 框架提供 Framework 和 WebService 及 APIService（也巧，貌似 知乎 和 Segmentfault 也用的Tornado）。Tornado 是一個單執行緒、單程式、非阻塞式的 Web框架，效能很不錯。Sqlalchemy 提供 ORM（Model層），這東西很好，尤其是對於我這樣不太擅長寫 sql 的人。Celery 提供了 worker ，完成一些不影響使用者使用的定時任務（統計）、耗時任務（發郵件）等，通過非同步，不阻塞主執行緒。Redis 主要用於儲存使用者的 token，資料庫用的是 MySQL（阿里雲RDS），同時還用了下阿里雲的 SLB 負載均衡（其實沒有什麼好均衡的，量又到不了知乎那級別，主要還是做https的支援和域名繫結，對Nginx不是很熟，17年要學一下了，畢竟 SLB 的費用一年也好幾百呢?）。
前端相對還是比較傳統，沒有完全使用 前後端分離 ，Vue 也沒有用到元件和元件化，主要原因還是剛學 Vue，沒有深入到元件，所以路由和頁面渲染，甚至html模組都是 Tornado 完成的。任何技術都需要循序漸進，如果現在再寫一遍，肯定不是這套架構，但在當時，這的確是最好的技術方案。但是服務端渲染也是有好處的，比如 SEO、頁面開啟速度，前端再怎麼優化，也沒有直接服務端渲染好 HTML 來得快。
iOS 和 Android App 是在 web 版全部完成後開發的，當時找了兩個對技術有追求的 iOS 和 Android 的小夥伴幫忙搭了殼，定製了一些 UI 和 Bridge 介面，iOS 用的 UIwebview，本打算用 WKwebview，但測試下來很多地方效果不是很理想，最終還是選擇了較為成熟的 UIwebview。整個移動端開發過程大概2個多月吧，也是基於 Vue + Gulp + Swiper 的，體驗還算不錯，尤其在 iOS 上。
運維是我的短板，Linux 不怎麼熟，所以很尷尬的就是一開始只能在自己電腦上玩，到了 ECS 上就蒙了。好在 TalkingData 大牛有的是，折騰了一週，所有的環境和庫都裝好了，找人幫忙寫了個 shell，就這樣上線了，上線後，就再沒斷過。
前前後後開發了有近半年，服務上線也快一年了，這套架構從沒出現過故障和報警，唯獨一次重啟機器把 Redis 資料丟失了。這個專案讓我對 全棧 有了更深的理解，但凡是後端的會點 Angular，前端的會寫寫 Node.js ，都不完全是全棧，全棧應該是能理解整個產品的命脈，並把它最終實現出來，安全執行。
推廣 Vue
我是 15 年雙十一那天加入 TalkingData 的。TalkingData 仍然還是創業公司，但規模和影響力要比我之前的兩家大很多，在大資料領域，更是領先者。
在這裡，前端團隊都統稱為視覺化，因為我們是跟資料打交道。其實 TD 幾年前是沒有專門的前端團隊的，由於歷史問題，很多產品線都還是較老的技術，公司的核心技術在大資料處理能力上，前端頁面很多都是寫 Java 的同事做的，用的最多的自然是 Angular（知道 ng 背景的肯定了解其中的原因?）。
我剛來時，做的是一個基於百度地圖 overlay 的大資料地理視覺化框架 TDMap（各種原因尚未開源），貼幾張圖感受下吧：
之後就是我的第一個業務類專案了，也是全面運用 TDMap。當時用的是 TD 自研的一套元件引擎和 jQuery。這個專案到最後做許可權系統時，才開始接入 Vue.js ，這應該是 TD 首次使用 Vue，不過當時也有限制，只用它做簡單的雙向繫結，但僅此一點，開發效率已經提高很多了。
在一個公司推廣一項技術棧也是有難度和技巧的，因為不同的人思考問題的角度可能會不同。新的東西一方面會增加學習成本，一方面對它潛在的問題是未知的，如果暴露出了問題或效能瓶頸，是否能夠處理或應急方案，尤其是選擇開源框架時，社群影響力、維護和持續開發都是考慮的因素。好在 Vue.js 給我們帶來了很多驚喜，社群反響也不錯，一句話就是用著放心。
既然嚐到了 Vue.js 帶來的甜頭，就要把它推廣起來，提高整個前端團隊的開發效率。
Webpack，又一前端神器
如果只是用 Vue.js 的基本功能，那其實只利用了20%的特性。
推廣 webpack 這一過程是緩慢的，因為開始和很多人一樣，以為又是個和 Gulp 類似的工具，所以有段時間仍然是使用 Vue + Gulp + jQuery 的技術棧，已經開始使用 Vue 的元件，但還沒有元件化。這樣寫的多了，問題就暴露了：
- 每個元件需要手動拆分html 、 js、 css 部分，維護成本高；
- html 需預先載入，所以會看到一個頁面有一大坨的html
業務第一，一開始也就沒有在意工作流，雖然麻煩，但也撐了幾個小專案。直到一個機會開始做 MarketingCloud營銷雲，才開始徹底學習 webpack，好在專案初期不太緊張，有了一週多過渡時間來搭建。
我覺得 webpack 的難點在於概念，因為你在開發時寫的程式碼，並不是最終呈現的程式碼。這對於傳統技術棧來說思維切換還是需要成本的，因此有了一個概念：編譯。
說到底，webpack 就是一個 .js 配置檔案，你的架構或好或差，都體現在這一個配置裡，隨著需求的不斷出現，工程也是逐漸完善的，一口吃不成胖子。這裡也分享一下 TalkingData 用到的工程配置：
github.com/icarusion/v…
關於 webpack 的技術介紹就不多扯了，掘金上有很多不錯的文章，不過也推薦我之前寫的幾篇：
這一年下來，這套架構在多個專案中得到了驗證，工作效率自然是提升了不少，也奠定了我們前端團隊的開發規範，Vue 的推廣，至此算是非常成功了。
iView，把開發效率再提高50%
經常混掘金的小夥伴，應該對 iView 不陌生吧！再貼一下地址：
github.com/iview/iview
也感謝大家的關注與支援，iView 的 1.0 工作馬上就結束了，計劃的 43 個元件，現在已經完成 41 個了，我們也承諾過，在 1.0 釋出後，會在 17 年初支援到 Vue2.x。
關於 iView 的介紹和使用，這裡就不多說了，可以看看下面三篇文章，這裡主要還是想說說關於它的一些故事和開源的經歷。
發起這個專案的初衷，是公司舉辦的一次創新專案活動，當時團隊正好也需要一套自己的 UI 元件庫，於是就申請了，從此就信心滿滿地開始了來源之旅，那時是 16 年 7月。
時間過得真是快，都開發 半年 了，也收穫了近 3000 ★。因為是第一次做開源專案，對 Github、npm 的很多東西還不瞭解，雖然平時都在用，但卻沒釋出過。慢慢地知道了什麼是 .gitattributes、.npmignore、.travis.yml、.eslintrc.json，也瞭解了 MIT、Apache Licence 2.0 開源協議，漲了不少姿勢。
iView 在一開始時，還是暴露了很多問題，比如必須通過 webpack 才可以使用，而且還得配置 babel，否則無法編譯 node_modules/iview 下的檔案，就這一個簡單的配置，折騰了很久，因為不同平臺不同版本，寫法不一樣。後來在 @jingsam 的 contribution 下，優化了 iView 編譯過程，最終不再依賴 webpack，也不需要配置 babel，在此特別感謝下 jingsam，雖從未見面，卻對技術有著同樣的追求。
iView 基本是我一個人在開發和維護，不過有一位在美國上大學的同學也多次貢獻程式碼，我們的溝通似乎並沒有時差的概念，因為他基本很晚才睡，夜貓子型別的 @rijn，在此也特別感謝。
iView 的 contributors 並不多，也藉此機會，希望更多對技術有追求的朋友能參與到 iView 2.0 的開發中，把它一起做好。
因為太想把 iView 做好，所以在寫每個元件前，都看了很多別人的實現，比如 Element UI、vue-antd、AntDesign、vue-beauty 等，這個過程學到了很多東西，看別人程式碼的確是最快最有效的學習方法，因為有時候思路會被限制，看看別人的實現，才能開啟思路，多加對比，也能知道幾者之間的差距。
現在公司最核心的服務 — 應用統計分析已經開始用 iView 重構了，相信在 2017 年，iView 也會像 Vue 和 Webpack 一樣，被很多專案驗證。
後記
16 年可以說是工作以來進步最大的一年了，學習了很多前沿的技術，也做了不少東西，但做技術的就是這樣，接觸的越多，越能感到自己的渺小，17 年繼續加油吧！
作者：樑灝
文章首發於掘金，未經許可，禁止轉載