2016个人心路历程：从 Vue 到 Webpack 到 iView | 掘金技术征文

时间 2019-11-06

标签个人心路历程 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 用到的工程配置：
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 年继续加油吧！

做者：梁灏
文章首发于掘金，未经许可，禁止转载