没有一点点防备，也没有一丝顾虑，2017年的一半就这么飞过去了……
“回头看看，是不是离梦想又更远了呢？”
“滚！”
前端
其实这个上半年过得蛮刺激的，挑战了一个自己以前没什么工程经验的领域——网站前端。
我们公司每年会填一份年终总结表，里面会问到之后一年你想在哪方面提升自己。在去年年初写前年的总结时，我给自己的目标就是学习前端。不过后来由于项目分工，我还是主要做着后端的工作。
那时我们大部分时候的网站开发主要还是两种比较传统的方式：一是后端HTML模板，二是后端API和前端jQuery+AJAX。直到今年年初，在农历年前时，我们要做一个交互比较多的网站，而且很可能会先上一部分功能，再根据用户反馈做调整和扩展以后，才定第二版的细节。开完那个网站的需求讨论会后，我认真考虑了一下，觉得后端HTML模板的方式很难满足这个网站的交互性，而如果用纯天然原生态的jQuery+AJAX，发布第一个版本可能还不太难，但要在这个版本上再调整和维护，就可能非常麻烦了——毕竟在重后端的团队，想把前端的工程化做好，并非一朝一夕的事情。
面对这种有一定挑战的项目，我经常表现得不(ai)够(gao)成(shi)熟(qing)。纠结了一会儿，我跟原型设计师说，我会把一个最基本的线框原型先用Vue划出来，然后她再到相应的组件里填CSS。
扑通～成功给自己挖了一个新坑。
其实早在14年底的时候，我就已经注意到了Vue这个轻巧的前端框架。当然那时的Vue还是一副“简易版Angular 1”的样子，不过那正是吸引我的地方——我在以前的实习用过一小阵子Angular 1，当时经验和认识比现在还浅得多，除了Controller以外写得真是一脸懵逼，用起来和带命名空间的DOM操作也没有两样。基础都用不明白的框架还怎么深入学习？学得不深入还怎么在组内推广？和Angular的一身武装相反，Vue总有一种T恤短裤，分分钟就能搞懂并上手的感觉。不过我做为一个没什么前端经验的小菜鸡，之前一直没折腾出超过hello world级别的小demo。
这下好了，把自己逼上梁山——直接用一个工作上相对有挑战的项目，来在第一手的实践中学习新姿势——不成功便成仁，啊不对，便走人。在用vue-cli把项目架子搭好之后，对着文档强改硬撸了几下，还真把最基本的线框UI画好了。接下来就要考虑状态管理了——这还真是个纠结了好一阵子的决定：是就用最直觉的vuex呢？还是设计一下加上rxjs这样的高端货？这个问题我纠结了快一天，终于先把rxjs放下了，毕竟项目也是有死线的，不能无止境地调研新玩具。
不记得从入手到有基本功能花了多久，反正这个网站倒饬倒饬还真按时上线了。现在回头再看，深刻的感受有四点：
- 拖延症患者拿公司项目来逼自己学习，起效真是飞快。之前我在业余时间下过多少次决心想把Vue学起来，全都默默地无疾而终（哪门子无疾，拖延症不是疾是什么？！）
- 这种事情不能多干，玩脱了就惨了。当时我也是冒了挺大的风险，在没有老司机带路的情况下强行瞎倒腾。如果项目没法按时上线，对我自己和对我们组都有很大的伤害。我也为此在遇到一些困难的时候担心过。
- 当然上不了线是最严重的结果，但是除此之外我当时还有另一层考虑，就是这个项目如果写完了，真要推广起Vue的应用，可能会有小童鞋在做新项目的时候，翻这个项目的代码找参考实现。所以我在实现功能和代码设计上时常会陷入一种平衡的纠结——是试出个方案就草草了事？还是多想一想有没有更好点的实践，来给之后的童鞋多一些线索和方向？
- 没有部门和小组对技术选型的开放，就没有搞事情的余地，没有搞事情的余地，就难有技术上的成长。
在这次试水以后，我在三月开始安利大家用Vue来做工程化的前端。组里的小童鞋们对Vue的学习情况都不错，新的需求和功能基本上都可以正常实现和交付。除了三月底四月初做的一个新网站，需要用一个vue-router guard来实现一个稍微难搞些的转页效果以外，其他的都顺利解决了。哦对了，四月还被安排去台湾出了个差，和做原型的设计师同事一起交流了一下，也算是入职以来的一次解锁吧。
有个独立于上面这一大坨东西的事情，也需要特别记录一下。最近的一个网站要用Canvas来画泡泡。根据Codepen上一个demo做出来的第一版，占了我50%的CPU，泡泡又各种锯齿，简直跪得双膝出血……后来找了一个上海分公司的React老司机帮我调整Canvas性能。他大手一挥，甩回给我一个泡泡均匀绵密，CPU占用不到15%的版本，直接收走我的膝盖。从他那里学到了Canvas的离屏渲染，实在是太涨姿势了。一方面要感谢一下老司机带路，一方面自己也要多打怪多升级啊。
还有一个值得小提一下的事情。有一个历史遗留网站，之前没有很好的工程设计，现在前端要加新功能了。我尝试着用MVC的思路写了一个完全独立的模块，纯闭包无原型也无Class，用Axios取后端数据和模板文件，用Lodash来编译模板，把这个纯粹基于DOM操作的旧系统扩展给吭哧吭哧送上了线，也算个有趣的设计模式练习。
后端
之前对OpenResty就一直很有兴趣，尤其是它的性能。继去年用它写了一个简单的服务做调研以后，我对它的开发体验也非常满意。在Nginx里用OpenResty写服务，其实和Flask有很多相同点，都是以URL为入口找相应的handler（或者说视图函数），也都通过一些特定的“魔法”来封装一个请求生命周期会需要的功能，如Flask里有request这个线程安全的“全局”变量，而OpenResty里则把所有相关的接口都挂在ngx这个对象上。
今年初把前端的框架技术选型定下来并玩爽了以后，就开始着手重写我们和游戏对接的服务。之前我们把游戏的API或者DB调用，用Django封装了一层统一的API，做一定程度的业务逻辑隔离和访问控制。现在这层API在访问量大的时候会有一定抖动，而且开发的准备步骤很复杂，文档也相对欠缺。我在去年年底的时候就盘算着，找个机会把这个服务用OpenResty做一个统一的网关，然后在内部再转发到不同游戏的“微服务”上游，这些游戏相关的“微服务”可以用OpenResty来实现，也可以用Python来实现，依库的完备程度和服务的性能需求而定。
我花了近一周的时间，用Nginx的共享内存做存储和全局任务锁，搞出了一个兼容旧数据库设计的认证网关。经过初步的测试，开发笔记本上的一个Docker容器就可以达到目前线上两台物理机的性能，果然异步大法好啊，还少了一层DB的IO。然后又用了一周多的时间，把一个游戏的大部分API用OpenResty实现了一遍，在这过程中通过各种尝试和反复重构，根据我们这部分API基本是做上游API和数据库的封装和转发这一特点，初步制定了一套非常简单的API文档和测试接口规范，并用一个很小的工具模块封装起来。不过这些重写的API只定好了测试接口，测试用例还没来得及跟上，就又双叒叕有新的前端任务杀过来了。我准备等测试得完整了以后再把新的API部署上线。
技术不太相关的其他
受到蔡学鏞在微博的推荐，今年年初我终于把约翰薯黍的《软技能》给看完了，从中明白了不少道理——很重要的一条就是，程序员其实也是一个销售工种——我们卖的是服务，无效的交流要排斥，但是没有必要排斥交流本身。所以我在上个月给一个童鞋做项目需求接口，一起把一个在去年就有计划，但是因为部门间的交流问题而一直搁浅着的项目，一点一点地调通并实现了。从这件事情中，我也认识并实践到了不少跨部门交流合作的沟通方式。
另外一方面，从最近一年搞的这些乱七八糟的事情来看，我觉得我有时在和小童鞋的合作中不是很有威望。组长大人跟我说，应该是我和小童鞋们关系太好，不容易竖立威信；另外一个老员工跟我说，应该是我给小童鞋太大的压力，以至于有时起了反作用——我想可能他们都对，人总是更注重关系好的朋友对自己的看法，也就更容易感觉到这样的朋友对自己的压力。最近读到的一句话可以记下来慢慢参悟一下：世界上最傻的事，就是对年轻人掏心掏肺讲道理。不过明明对项目的交付来说，组长和老员工是要对质量负责的，不讲道理的话难道发火和用强权不成？不懂啊不懂（喂，说得你自己这只小菜鸡就很老一样啊你个傻X）
展望
呼……不知不觉居然写了这么多（我果然是个嘴炮选手啊），该给下半年定些目标了。
现在我们已经入手了一个前端的框架，对团队来说，最重要的就是大家的CSS水平也要跟上，这样团队的前端综合实力才不会被制约。所以接下来一个很重要的任务就是要提高自己的CSS技巧，引入一定的CSS规范，让网站静态原型的工程质量能在保证外观的基础上，对后期的JS+API对接更友好。然后在此基础上调研一些常见UI组件的实现方式，并把可复用的UI组件文档化、系统化地管理起来，方便大家的随时引用。
另一方面就是继续提高网页的交互性了。这里有三块内容：一是我希望能多了解一些SVG的API，特别是如何用Snap这个库来让SVG的控制更有效，然后用SVG来到达更好的网页效果；二是我觉得我们现在的webpack项目构建流程以后还可以再加上图片的压缩和雪碧化，这个可以抽时间来调研一下下，提高网站的加载效率，也省下开发和设计师同事的时间；三就是进一步调整网站静态资源的缓存策略，还有Nginx的配置细节，让网站的响应更快——这点感觉可以多从屈光宇大牛的博客里学习学习。
说到Nginx，我们的Relay API也需要找个空闲些的时间来把集成测试用例完善好，再把新的服务部署起来。毕竟这个是我们部门最基础的服务，而且OpenResty也是我近几年最想深入了解的技术。
昨晚看到一个很符合我三观的Ted演讲，就以它为结束好了（习惯用Markdown写文章没法直接插入视频）——在奔三的这十年中期，不求活得通达明白，但求过得认真无悔。
