今年主要还是react，小程序，koa2。
react从之前的15.6版本一直迁移到16.4版本。包括配套的raact-router 升级到4.0+
从满篇的重复代码，到各种封装，以及hoc
redux->dva->mobx-rematch
koa2基本上主要还是做api中间层，做接口合并转发，以及多端统一的问题，并未接入渲染层。
小程序用内部的wemix开发(里面坑点也是不少),movue刚出的尝试后，尝试帮朋友写了一个小程序
react
react可以说是从会写一点，到熟练了不少。并且在几次的项目基础模板重构中，也发现了之前模板所存在的问题。
- 开发效率
- 开发规范
- 组件封装
在原有的项目中，为了快速的上线，项目基本上都是从另外一个项目拷贝多来，然后直接进行开发，在项目路由处理上，公共组件，以及一些HOC的封装上，都存在这不少的问题。后面发现，有些项目基本上是在做重复的问题，这个时候，才发现，真正的提高效率，满足快速的项目上线的前期，是减少很多重复工作。之前总觉得，花时间去搞这个，太耽误时间，后来发现，这个是势在必行了，但是业务开发还要继续，只能在业余时间来搞。
4-6月份，感觉应该是鸡血满满的时候。经常自己搞到凌晨两三天，还觉得特舒服。团队不再打算使用纯redux进行开发，因为繁琐的action，reducer定义，确实让人头大。前期用dva，虽然解决了这个问题，但是也带来了一些新的问题。比如，并不能使用回调的形式来解决操作类事件的结果反馈,只能在componentWillReceiveProps生命周期进行判断。在家上dva基于redux-saga,用的是generator,写起来真的有点麻烦。最终选了mobx。
既然定了mobx，那就一定要有模板来支撑了。项目的模板，首先要满足的就是，让其他小伙伴开发的时候，不需要去过多的了解底层怎么调用，我们应该把一些稍微底层的东西全部封装，或者至少提供模板来告知，来减少他们的学习成本，使其能快速上手项目。犹记得那昏天黑地的两天，github上各种找，google各种搜，最终两天的时间还是把模板搞好。并在后续的开发中进行了完善。
后面，针对webpack进行了一次升级。直接升级到最新版，将原来的插件进行兼容，将项目打包速度以及构建资源的包都提升了一个档次。
这样先提升了项目init，以及coding时候效率。
后来团队统一使用vscode，发现vscode有code Snippets 代码，于是又整合了部分常用的，加上mobx定制的，从原来的cmd + A，cmd + c, cmd + v,然后删除里面不需要的内容，到四个字母搞定，效率似乎提升了N倍。
在开发规范方面，当时虽然有eslint，但是初期的时候，并没有被重视，并且当时并不能自动修复，而是手动改，很耗时，也很麻烦。最后导致的结果是，可以手写符合eslint规范的代码。虽然编译器提示红线警告，那能不能自动来修复呢？于是google一番，发现就是vscode plugins + prettier，于是团队统一eslint规范，并配置好prettier以及对应的vscode插件，这样，onSave, onPaste的时候，都会自动进行格式，简直不要太爽。最舒服的是，关于react jsx的处理。当出现三元运算的时候，dom结构之间的缩进是一个很麻烦的事情。有了这个，再也不用担心缩进对不齐了。
在开发后台系统的时候，用的antd，本身antd已经封装的很好了，但是结合到业务的时候发现，我们还是会做一些重复的工作。因为后台系统里面，充斥这大量的筛选框，表格，分页组件，每次都是拷贝过来。虽然拷贝效率上并不慢很多，但是拷贝以后还要改接口方法之类的，索性将这些组件再做一次封装，这样一来，将原来的编码化改成配置化，效率似乎又提升了很多。
这些东西，实际上并没有花费很多时间，比想象中要少。而带来的结果，确实让人很兴奋。原来的后台系统，可能开发时间预估在3-4个工作，这样一来，效率提升了50%左右。旁边的产品汪以为我们还在苦逼的切图的时候，我们已经等待联调了~
很多人不喜欢业务开发，觉得很无聊，都喜欢自己搞一些东西，刚开始，我也这样认为。觉得业务开发并不能带来多少技能的提升，顶多只是技能的熟练。但经过这一系列的优化发现，如果我们能发现问题，并且积极的去解决问题，我们一样可以获得技能提升。技能的提升不能总在理论层面。如果不结合业务，或者说，所产出的东西并不是为了解决问题，那么它的使用场景就很局限。日常业务开发的都要求快速迭代，并且要保证交付。遇到朋友的一些情况，他们的项目经常的延期，我想他们可能也许去发掘问题，解决问题，以致带来一些质的飞跃。
关于框架选择的问题
去年一年，react的状态管理框架，可谓真的是将市面上的都用了一遍。最终在年底的时候，决定使用rematch。
我们自己部门内部，本身是要使用mobx，因为好几个项目都在使用了，但是想做整个公司的前端统一，又出现了分歧。
我们老的项目使用的redux，如果强行切换mobx，首先就要重构。重构需要花费比较大的时间成本，而有些老的项目，一直在添加，导致路由已经200+，这样的项目如果做redux->mobx的迁移，想想都会头大。这个时候，就开始在github找东西了。发现mobx的作者，又搞了一个rematch，当时只有3000+ star，于是就瞅了瞅。这一瞅，又是给自己找事了。。
首先，他还是基于redux的，形式类似dva，但是要比dva用起来舒服。其次，他可以完美的兼容原有的redux。并且issue的处理速度，以及版本的更新都让人满意。那么接下来，又得搞事了。于是，新的模板出来了。。
在选择框架的时候，我的本意是，我们这边都比较熟悉了，就拿这个来用就好了，并且对应的配套也都比较完善了。但是我的出发点，并没有兼容老的项目，因为我们部门的业务原因，好多都是新开的项目。框架的选择，应该尽可能的满足大部分人的需求，以及大部分项目的需求，不能脱离项目，脱离业务，否则，完全就是在耍流氓
小程序
顺带也将2019年年初的事情说了。前期的wemix(团队内另外一个伙伴开发的),仿照wepy进行开发的，当时小程序不支持组件化，而我们的技术栈是react，wepy是类vue写法，让我们写起来或多或少会不舒服。但是在后期的使用过程中发现，这个脚手架的扩展能力不尽如人意。如果想扩展，就必须去修改源码。
这个时候，跟那个小伙伴也商量了一下，因为看了一些webpack的构建流程，了解到了tapbale，以及webpack的文档，发现我们也可以仿照这样的形式来完善我们的脚手架。于是新的立项出来了。我们要是用tapbale重写原来的脚手架(正在进行中)
koa
2017年的时候，用过exprss，后来就一直在玩react了，去年，我们因为项目需要以及服务端的改造，node发现了使用场景。前端都是爱折腾的，我们就加了一层api中间层。对于服务端来说，他们也希望我们这样做，因为他们用spring cloud 做微服务，服务拆分以后，如果他们不做接口聚合，那么，我们每个页面的接口访问都会倍增，同时，新的项目是h5 + 小程序 + app。于是，这一期，前端自觉给自己加了工作量。开发中，服务端真的是清闲了不少，真如那句”前端忙成狗，后端写sql”，但是我们也觉得很值，我们已经将手慢慢的伸向了服务端~~~
在后续的过程中，经常会有一些营销活动，生成分享图片之类的，这些图片的生成在各端实现是有差异的，我们索性直接做在了node层，用node层直接提供图片流，给各端。
另外一个新的项目，项目不大，但是功能却全面，包含微信授权支付等。本来我就安心的做个切图仔就好了，可是服务端搞事情啊。他们为了使用他们的中心化服务，强制要求添加node层，然后说图片上传要不node也写了？脸上变现的十分不乐意，心里面暗自窃喜，等到我连DB也连了，你们就可以失业了，哈哈。(不要以为是团队不融洽，恰恰相反，是考虑那边做的成本更低，或者说更方便)
技能
之前对于框架源码这些东西，指向说，不可能看的，打死都不可能看的，现在只想说: “真香”.
虽然刚开始的时候看着是比较痛苦，但是后来，慢慢的看进去发现，这又是另外一个世界。一些奇淫技巧，一些编程思想，一些…
只能说真香，这里不做赘述，后续会写一些关于阅读源码的一些理解
昨日已去，应该更好的把握现在~今年，继续加油喽~~