作者：蛋疼的axb
眼看着又一年结束，想想今年过的还真是快，上个画面还是去年年末各种处理故障的场景，一眨眼一年就过去了。既然过了一年，还是得留下些思考和展望，否则就有些太无趣了。
还是套用那个老的不能再老的梗吧，the good,the bad and the ugly。
The Good
今年职位从高级码农变成了看上去很忽悠人的”技术专家“，虽然按专家的头衔来说应该做一些更深入的研究工作，不过受限于身体状态一直不好，一认真的思考问题就会头昏脑涨，只好做了很多给团队打杂的工作，所以好的部分大多数不是我个人的贡献，而是团队的功劳。
今年最主要的成果，应该是跟团队一起在很多事情上兑现了之前一直念叨的“应该”。
应该从现在开始做重构，而不是“到时候”
从去年接手团队之后就一直在跟历史代码做斗争，在做了很久看似出工不出活的“代码review”、“重构”、“增加测试”、“删代码”之后终于有了回报：我们的代码质量可以让我们在其中正常工作，不再需要为了一个看似简单的功能而大动干戈的在“屎一样的一大坨代码”里纠结半天了。
我们试过很多办法提升代码质量，包括强制code review、专门抽出时间重构、周会上的代码评审等等。每一种都或多或少的有一些效果，但最有效果的做法是引入自动化的代码风格检查工具，可以发现大部分代码细节问题，并且很容易量化，对于“质量”这种没有实感的东西，量化是能够让你持续投入很重要的一个方面。
而最终的收益不仅是开发效率的提升，更重要的是，一个不断进化的团队中的一员在看到烂代码时，感受到的是“如何解决这些问题”的挑战，而不是”这些代码再也不会好了“的无力感。
应该通过提升开发效率完成工作，而不是靠加班
有代码不断优化的基础，我们也很自然的把服务过渡到了微服务架构。微服务架构让我们能够更敏捷的工作，不再需要忍受单体架构带来的“一个巨大的黑盒”带来的不便，我们可以对性能做更细致的分析，对问题做更精确的定位，对技术选型也有更多自由。在此基础上建立起了持续部署系统终于把上线变成了一件日常工作，“等我5分钟，我review代码的时候发现个bug，上个线就去吃饭”。
我跟很多人谈起这个“5分钟上线”的时候，他们都觉着我是个不负责任的人，并且一遍又一遍的问我：“上线上出问题怎么办?”
问我这个问题的人一定是没有考虑过“复杂度”本身就是一个巨大的问题源，当代码足够简单、依赖足够清晰时，很多问题就自然的消失了。实际上，我们现在的上线次数从每周两次提高到了每天十几次之后，上线产生的问题已经几乎不存在了。
应该通过报警发现问题，而不是用户投诉
我去年用几天写了一个报警系统，团队又在此基础之上建立起了一套特别靠谱的报警服务，不再依靠“检查系统内部有没有问题”，而是站在用户的视角，依靠探测程序检查“用户在使用时是不是有问题”。
站在用户维度报警的好处是，只要有报警，那么就一定有问题。于是我们终于从每天轰炸式的报警短信中脱出身来，不再需要“按报警频率估计服务有没有问题”这种无用的工作，也不需要面对boss“怎么用户都投诉了你们还不知道”的尴尬问题。只要有报警，那么就需要处理;反过来，只要没报警，那么绝大部分用户使用也不会有问题，我可以放心的玩《守望先锋》而不用担心boss会突然来电话。
最终，有惊无险的，我们做到了服务全年无故障(虽然还有几天才过完今年，希望这不是一个flag……)。
应该通过技术解决性能问题，而不是堆机器
微博的访问量极大，做个方案动辄要支持百万并发、千亿数据，但奇葩的是公司又很穷总是买不起新服务器(-_-)，性能优化就变成了极其重要的工作。
我们今年做了不少应用的性能调优，把每个服务的性能指标都提升了几倍(还有几倍是留给明年的KPI的-_-)。性能调优是一件有挑战又有成就感的事情，而且比较有意思的地方是，无论程序员的水平是好是坏，总是有调优的空间。水平弱一些的同学可以调优业务代码和基本参数;好一些的优化架构和第三方组件;牛逼的可以深入jvm和内核原理。调优经验多了，总会有种“无论怎么优化也到不了头”的感觉。