本命年一定要记得穿红裤衩:2015年总结

年终总结效果到这个时刻才写,实在也是没法。原本设想过年写的,没想到Steam居然开了个夏历春节特惠,然后就被种种游戏打了,辣鸡平台,敛我财帛,颓我精力,耗我芳华,害我只身

以下全都是个人意见,假如有不认同的处所,请大吼一声“傻逼写的啥”然后封闭页面

转职

本命年终究快过去了,不知道是否是因为没有穿红裤衩,这一年有许多不顺心的事变,不过也有许多功德。这一年最重要的事变就是顺遂从一只门生狗转职为一只社畜。四月份毕业今后之前端工程师的职位入职天猫,到如今也差不多事情一年了。这里写一下干这行以来关于“前端”这个行业的意见和感悟。

前端工程师在校园里是一个庞杂度和职位都被严峻低估的职位。先生们对生长迅猛的前端手艺不够相识,更是有不少“师兄师姐”在引见本身找事情履历时“xx天速造诣找到一份前端事情”、“公司雇用前端也不问会什么,就问你肯不肯踏实干这行,肯干进去再教你”。固然学校里的项目里也会有页面,但因为先生和门生对前端种种手艺的生疏,大多数都是运用jQuery聚集代码完胜利用了事。在人人眼里,写页面没啥手艺含量。

前端的许多基本学问,都没法在学校学到。学校先生交给门生的大多都是基本学问,比方算法、数据构造、编译道理、操纵体系、计算机网络这些,而针关于特定范畴就很少触及了。见过学校开设C、C++、Java、PHP等言语的课程,却从来没有看到过开设JavaScript、CSS、HTML的课程。网页设想的选修课却是有(我报了,很遗憾悉数课堂只需20人不到),但这里所谓的网页设想并非前端那一套手艺栈,而是Dreamweaver运用入门。前端手艺栈在校园里没有提高。

就如许产生了一个很有意义的征象:大堆公司喊缺前端,而门生们并不知道前端是什么,怎样去进修前端学问(近来两年轻微好点了),他们更多的是去学Java、C++,走着师兄师姐们走过的途径。有幸如今已有百度这类大公司注重到了这点,到高校里开了不少前端学问讲座,还在GitHub上搞了培训项目。

愿望各个大公司的前端部门能够更多的走进校园,给对前端感兴趣的小朋友们一点指点。

React

客岁上半年4月份入职打杂了一段时刻今后,就最先进修React而且举行了一些实战练习训练:

  1. 产出一篇文章轻松入门React和Webpack,不测的很受好评,segmentfault上超过了200的珍藏,tmall的github博客上也有不少批评。惋惜如今文章中已有许多不适用了,babel大版本到6发作了不少变化,当地调试也改成中间件了

  2. 把本身的博客lingyu.wang改成了全React完成,代码在这里,用react-router做了个单页面运用,底层照旧基于hexo,本身给hexo写了个generate插件把一切数据天生json而不直接天生页面,为了练手已丧尽天良了,SEO什么的完全不在乎

  3. 写了一些脚手架和组件,杂乱无章拜见玩具箱

因为担任天猫最庞杂的前端运用之一的开辟和保护,有不少老代码,也因为迁徙本钱太大没有办法在Java层上插进去Node.js中间层,种种模块之间种种耦合,中间也写了篇用React做重构时的一些思索。当时项目里存在以下几种耦合:

  1. 最蛋疼的就是压根就没有模块化,一切代码都在一个文件里,2k+行的jQuery那种。最老式的写法,也是在学校项目里看到最多的体式格局,挑选器拿到DOM然后操纵绑事宜,大多多年前的代码或许是后端兼职写的。基本上没有可保护性。处置惩罚这类基本上就靠推倒重写了,斟酌投入产出比看懂它的本钱还不如从新写一个来得快

  2. 轻微好一点的是增添了模块化,但模块内部和之前思绪没什么辨别,只是把上面那种代码离开多个文件放了。差别的模块在模块内部操纵雷同的HTML,一旦个中一个模块转变了HTML构造,其他模块直接就bug了…

  3. 再好一点增添了前端模板引擎,各个模块都在内部运用模板引擎衬着本身的HTML,模块初始化传入一个容器,只需容器不争执,模块之间就不会基于HTML耦合。模块会暴露一些接口,经由历程模块管理器猎取实例相互之间直接相互挪用,如许照旧是强依靠,两个模块相互依靠,一旦个中一个换了,接口变了,别的一个模块也须要转变本身的代码。

  4. 模块内部完全黑盒,只需一个容器,内里的内容由模块本身掌握。模块有数据的进口和出口,进口就是一些由父模块或页面传入的设置,出口则是一些由父模块或页面传入模块回调函数,回调函数内里附带传出的数据,而HTML相互之间没法相互修正,改了就报错。没错这就是React

末了重构的计划定下来是React+AMD+Gulp(你没有看错,没有打包,没有webpack),之所以不打包主假如有老代码,组件页都没宣布到npm上,而且因为阿里的CDN支撑combo,所以也就不做打包了,至于运用React做重构,主假如因为以下几个缘由:

  1. 运用React完成的模块和组件完全黑盒,Web Component理念,标签运用轻易快捷。不会引入新的保护本钱

  2. 组件轻易抽离,构成沉淀。我曾把一部份新营业运用React完成,个中的不少组件略加完美就沉淀出一些基本组件,没有剥离本钱

  3. 模块相互之间不会污染,没办法直接修正其他模块的DOM,改了就报错,然后QA就提着刀杀过来了

  4. 商家运用,许可全异步,富交互功用型页面,机能不太烂都能接收

现在新营业已完全基于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

Node.js给前端开辟流程自动化带来了福音。从现在部门前端开辟流程来看,重要就是以下几个步骤,括号里是对应的开源东西:

  1. 建立项目(Yeoman)

  2. 构建以及监听文件变化自动构建(Gulp、Webpack、Grunt,Grunt预计如今用的很少了)

  3. 当地调试,资本代办(Koa、Express+种种定制的中间件)

  4. 自动化测试、代码覆蓋率测试(mocha、istanbul、should/chai/expect、phntomjs、karma)

  5. 文档自动化天生(本身基于AST提取,或许直接用jsdoc之类的东西)

  6. 自动化校验、宣布(一些剧本)

这里重要聊聊构建、当地调试和自动化测试

构建

如今的构建历程已不再像之前那样紧缩一下就简朴,构建历程当中每每会拿代码天生语法树然后做种种操纵:

  1. Babel爽爽写ES6以至ES7

  2. 将代码中的解释转化为监控办理(istanbul我记得就是基于语法树给每一个语法分支包一层办理层,汇总数据)

  3. 将代码中的解释提取天生文档(React组件自动天生props文档就是这类体式格局)

  4. 将commonjs范例的代码转化为林林总总的模块化处置惩罚计划(AMD、KMD、UMD等等)

  5. 提取模块间的依靠关联,梳理运用模块依靠关联,绘制模块依靠树

  6. Webpack打包

  7. 种种语法搜检(eslint,jshint),有时刻还会有一些定制化的校验

如今人人都比较中意webpack,依靠打包使得资本要求数大幅度削减(运用不支撑combo的CDN效劳的公司一定很高兴)。我个人照样关于webpack有一些挂念,重要有两点

  1. 不太赞许浏览器内运用的资本也宣布到npm上。浏览器上和Node.js通用的代码能够也就不到5%(lodash啊,underscore啊,moment啊这类),在npm上找到一个模块还要确认究竟哪一个场景下可用。运用的即便是这些能够共用的库,也会有一个很蛋疼的题目:Node.js的模块每每大而全完成尽量多的功用,而页面运用的模块则是尽量小而美,资本加载量尽量少。比方只用到时刻格式化和反格式化就引入一悉数moment(moment真特么大,我平常就格式化反格式化,喜好用fecha),关于Node.js或许没什么压力,但关于页面就很蛋疼了。如今rollup试图处置惩罚这个题目,照样比较值得看好的

  2. 差别版本反复打包的题目。这个题目比较头疼。假如一个项目依靠了两个组件,而这两个组件引用了一个库的两个差别版本,这个库就会被打包两份,因而乎代码量就duang一下增大了。现在照旧没有看到比较好的体式格局来处置惩罚。虽然能够用peerDependencies对一些基本库(比方React这类)做一下处置惩罚,也只是减缓一些罢了。

别的吐槽一句,webpack设置真烦琐啊,个人现在偏向的计划是运用webpack+gulp,webpack担任打包和构建,其他的事情照旧交给gulp,我喜好stream(不是steam)

当地调试

前端资本当地调试实在挺简朴的,就是把线上运用的资本代办到当地资本。因为如今平常都邑运用CDN来承载这些资本(假如你们公司不必CDN,请找你们老板拨点经费买个CDN效劳吧),大致上也就是几个步骤:

  1. 把CDN的域名经由历程host指向当地

  2. 在当地80(HTTP)或443(HTTPS)端口开启对应的代办效劳,依据要求查找当地资本返回

  3. 假如触及须要开启多个效劳,将各个效劳开在差别的端口后在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种计划:

  1. 构建一个测试页面,人肉直接到假造机上开种种浏览器跑测试页面(比方f2etest),这个题目就是不好延续化集成,人肉事情较多

  2. 运用phantomjs构建一个捏造的浏览器跑单位测试,大致上就是先用gulp-istanbul给代码办理,然后拿mocha-phantomjs跑包含测试用例的页面,末了经由历程hook拿到效果用istanbul天生可视化的覆蓋率页面,蛋疼就是phantomjs毕竟是Qt的webkit,不是实在环境,phantomjs也是种种坑

  3. 经由历程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游戏:

  1. 怪物猎人,沉迷了一段时刻,以至一整天一整天的和种种龙做奋斗。如今怪物猎人累计游戏时刻应该有250小时了…

  2. 口袋妖怪X:硬着头皮啃英文,撸宠体系好棒,天天撸一撸本身的宠,看到他们高兴的模样本身也高兴。通了一周目就懒得啃英文了

  3. 牧场物语,在同事引荐下玩了,模仿运营农场,种菜、种果树、养种种动物卖钱…玩了几十个小时吧,玩不下去了…背面天天刷牛挤牛奶,撸鸡一天就完毕了…没领悟到游戏的兴趣

  4. 路易吉鬼屋,超级玛丽里的弟弟被拉到鬼屋里探险的故事,兴趣就是看路易吉这个大写的怂货被种种鬼吓尿…解密游戏,实在挺好玩的

  5. 马里奥赛车:和跑跑道具赛差不多,玩道具赛,道具比较少,赛道也少,难度也低。

  6. 勇气默示录:回合制RPG,还在龟速通关中,画面很棒,3D的人物很Q,相称不错的游戏

然后说一些PC的:

  1. 侠客风云传:情怀!相对的情怀!作为一个昔时武林群侠传的狂热爱好者,侠客风云传我通关了最少6次,托钵人、东厂、盟主、霸图、天王种种都通了一遍。湘云照样自始自终的女神,愿望徐大早日重制金庸群侠传

  2. 仙6:这个战役体系特么什么鬼…没有玩下去的动力啊

  3. 碉堡(bastion):很细腻的游戏,画面唯美,歌曲好听,剧情不长但很好玩。

  4. 进化之地2(evoland2):尼玛一个游戏能这么玩我算是长见识了,集DQ、塞尔达传说、超级玛丽、拳皇、双截龙、炸弹人、游戏王、洛克人、1943等等于一身的游戏也没谁了

  5. 阿玛拉王国:和老滚有点像,不过比老滚有袭击感,重要的是有WOW那种设备体系。老滚的设备体系是个鬼…惋惜没有老滚那末多mod,毕竟少女卷轴

  6. 饥馑:这游戏太特么难了,一到冬季就死…得找个大神带我

春节剁手买了昆特牌3和龙腾世纪,有时刻玩一玩。末了重申一句:辣鸡平台,敛我财帛,颓我精力,耗我芳华,害我只身

情绪

看他们的总结都有这个,因而我加上了

光棍年纪++

总结

前端生长太快,要学的太多。原本客岁设想学React Native的,效果只写了个Demo…Electron也是只跑了个HelloWorld…Node.js的效劳器也只是搭了个简朴的…canvas也是只写了一些小Demo。愿望新的一年手艺不落伍,能够多学点这些之前想学没学的东西。别的愿望能够沉淀出本身的组件库,今后疾速搭建一个页面也轻易一些

    原文作者:天镶
    原文地址: https://segmentfault.com/a/1190000004479178
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系博主进行删除。
点赞