2016個人心路歷程：從 Vue 到 Webpack 到 iView

時間 2019-11-13

標籤個人心路歷程 vue webpack iview 简体版

原文原文鏈接

2016年工做中作過最自豪的兩件事情：css

把 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 的要求都要低，概念理解起來也容易。html

比起 Angular，Vue 最大的特色就是對數據雙向綁定這件事處理的很優雅。ng 中你須要注入依賴服務，好比 $scope 和 $rootScope，變量寫起來也散落在各處，並且有時候還得用 $apply 來告知，這對於不少初學者來講是很麻煩的事情。我之前是寫 jQuery 的，因此仍是喜歡用 jQ 的不少東西，好比 ajax，而 Vue 在數據使用上很靈活，能夠引用外部變量，能夠在各類狀況下直接修改，不須要額外的工做，因此當看到 Vue 雙向綁定這一特性時，就決定嘗試用它了。前端

一我的搞了一個產品

從 14 年畢業到 15 年末，就一直在兩個規模不大的創業團隊工做，前後作了 5 款產品，都是 App，涉及的面也很廣，好比 Canvas、Hybrid 什麼的。在初創團隊工做就像打了雞血同樣，天天早上起牀都火燒眉毛地開始寫代碼，對工做的熱愛絕對不是隻把它當作一件賺錢的事情，全部人都是有理想和技術追求的，因此那段時間我作的東西都很用心、精緻。vue

兩年的創業經歷也把我鍛鍊成了一個對產品有理解、追求細節、美觀的一我的。node

從 15 年中旬開始，因爲項目須要，我開始接觸 Python，這也是我第一次接觸後端語言，之前對服務端的開發是一點不懂的。不知道是 Python 自己的緣由，仍是我理解的快，上手其實並不難，並且沒多久就已經能夠熟練的寫起來了（如今接觸的東西多了，以爲那時學習的快，是有一套很好的架構和有人帶，先能寫，而後慢慢了解其中奧妙，這種辦法對於程序員掌握一門新技術仍是頗有效的）。python

我相信但凡寫過 Python 的人，都會用優雅來形容它，好比一行代碼帶有循環的賦值：webpack

user_hash = dict((str(user.id), user.to_base_dict()) for user in users)

其實寫後端和寫前端，不少地方是想通的，只是概念上有區別。只不事後端專一在數據的獲取、緩存和整理上，加以各類服務，前端則在獲取數據、整理數據、可視化數據。git

學會了 Python，發現這個時候能夠本身獨立作一點東西了，因而就有了 一我的搞了一個產品 。不賣關子了，這個產品就是 TalkingCoder，從產品、設計、前端、後端、運維、iOS & Android 客戶端，幾乎都是我一人擼的了，只不過在寫移動 App 時，有兩位兄弟幫忙寫了個殼。程序員

從產品和技術複雜度上，TalkingCoder 很接近知乎和 Segmentfault，基於關注內容推薦的 Feed 流、文章、提問（最佳實踐）。看一下用到的技術棧：github

後端固然是基於 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 用到的工程配置： https://github.com/icarusion/vue-vueRouter-webpack 關於 webpack 的技術介紹就很少扯了，掘金上有不少不錯的文章，不過也推薦我以前寫的幾篇：

這一年下來，這套架構在多個項目中獲得了驗證，工做效率天然是提高了很多，也奠基了咱們前端團隊的開發規範，Vue 的推廣，至此算是很是成功了。

iView，把開發效率再提升50%

常常混掘金的小夥伴，應該對 iView 不陌生吧！再貼一下地址： https://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 同樣，被不少項目驗證。