本来没打算写这个的，但是公司要求交一篇年中总结…既然要写了，就写得认真点吧。
在2017年的年终总结里面，那时候我还在做前端，也写了我接下里感兴趣并想深入的点，机器学习，图像识别等方面的内容，主要是自己感兴趣的居多，和公司的业务关系不大，没想到过了记过月后就转型做服务端了，机器学习在看了几个月的资料后打算先放着，毕竟还是有点门槛，需要花大量的时间进去。
转型服务端之后，首先做了一个接口转发的项目，是用node的koa框架搭建的，了解了服务端的很多概念，比如中间件，basic验证，还有对mongodb的使用，甚至后面还申请了两台服务器搭了集群。
接下来就是做一些零碎的东西，比如集成微信登录这些。属于加深基础知识的阶段。
接下来又做了一个比较有意思的东西了，通过前端模板可视化搭建活动页面（项目名暂且叫活动模板）。
这个项目比较有意思的，刚开始也只是让我先去调研一下项目可行性，因为以前没做过这东西，不清楚里面会设计到哪些技术点，哪些能做哪些不能做，然后我画了四天时间（大概）做了一个demo，demo的功能很简单，页面展示一串json数据，json数据的内容可以自己随便改，然后有个保存按钮，点击保存后页面的json数据就会更新，然后会有一个发布按钮，点击发布后这个页面会部署到一个地址去，浏览器打开这个地址就能看到这个页面了。
这个demo其实解决了两个关键问题：
确定了项目可行后，基本上就开始做了，涉及到3块东西，模板，后台管理页面，服务端。工作量还是比较大的，然后就是一些细节问题，比如确定了通过复制文件的方式部署，那么就会遇到一台服务器怎么复制文件到另一台服务器这种细节问题。还有就是既然要让运营和市场配数据，那么怎么让他们配呢，需要有个表单把，这个表单还需要根据每个模板的数据格式动态生成把，还需要集成友盟统计，微信分享把，还需要定时上线下线的功能吧。后面大部分时间都在解决这些问题吧。这里就不细说了。
用过前面项目的积累，我对服务端的工作内容也是比较熟悉了。这个阶段，（自认为）基本的后端需求都是能做的了，接下来只是把框架弄弄熟，项目结构设计的好一点。
在后面就是公司要求学golang，因为之前用php做的接口在618或双11期间会有性能问题，所以之后的活动接口都会用go来做。其他还是用php来做。
然后就是用go做了一个618的比较大型的项目。这个项目中我是负责做service接口的，所以要和前端对接口，和其他后端拿用户数据。因为活动比较大，碰到了刷单的问题，有人通过大量的手机号来参加活动，中了很多奖，但是他的手机号是合法的，也是在tthigo注册过的，所以就没法判断是不是恶意刷单的用户，这算是一个漏洞，还得想想接下来怎么解决。
也是在这个项目里，我写了一个基于redis的任务队列，后来因为要和node打通，写了一个消息队列，这是后话了。
我只习惯定短期的目标，长久的太不靠谱了，希望在3个月内能掌握的：
我认为，开发人员真的是要前后端都有所了解，才能成为一个合格的web开发者。才会对以前的知识有所升华。
举个简单的例子，CORS跨域问题，一般的开发人员遇到跨域的问题就报给后端不支持跨域，没有更多信息了，但是有做过后端的话，就会知道跨域中包含了很多问题，比如是origin没加导致的跨域不通，或者是option方法不支持，又或者是请求头里面包好了特殊字段导致的跨域，这些错chrome都会报出来的，如果前端能给后端提供详细的跨域报错信息的话，那么效率也会提升好几倍，后端也会对你刮目相看。
和这类似的问题还有网络请求时，前端习惯以json的方式提交数据，但很多后端默认都是以表单的方式接受数据，就会出现前端明明传了数据，后端说没拿到这种问题。
再举个栗子，之前做iOS的时候，找了很多项目解耦的解决方案，那时我也只是单方面的吸收，既然他们这么做了，那我跟着他们这么做肯定也没问题。但是那是我一直有一点疑惑，他们设计了这个方案后碰到了棘手的问题该怎么处理？他们是如何保证这个方案遇到问题都能解决的呢？
现在我总算是有点眉目了，因为他们的设计方案都是和后端的框架设计方案类似的，比如我之前看的那种解耦方案是这么做的，借助iOS的runtime（反射机制），实现类似消息队列的功能，实现各个模块的解耦，再借助中间件的机制，在各个模块之间做通信的验证，比如验证登录这种。了解了这些，那前端的解耦方案只是自然而然的事情。如果遇到了问题，那么这个问题在服务端八成也遇到过，参考服务端的解决方式就可以了。