眼看着又一年结束，想想今年过的还真是快，上个画面还是去年年末各种处理故障的场景，一眨眼一年就过去了。既然过了一年，还是得留下些思考和展望，否则就有些太无趣了。
还是套用那个老的不能再老的梗吧，the good,the bad and the ugly。
The Good
今年职位从高级码农变成了看上去很忽悠人的”技术专家“，虽然按专家的头衔来说应该做一些更深入的研究工作，不过受限于身体状态一直不好，一认真的思考问题就会头昏脑涨，只好做了很多给团队打杂的工作，所以好的部分大多数不是我个人的贡献，而是团队的功劳。
今年最主要的成果，应该是跟团队一起在很多事情上兑现了之前一直念叨的“应该”。
应该从现在开始做重构，而不是“到时候”
从去年接手团队之后就一直在跟历史代码做斗争，在做了很久看似出工不出活的“代码review”、“重构”、“增加测试”、“删代码”之后终于有了回报：我们的代码质量可以让我们在其中正常工作，不再需要为了一个看似简单的功能而大动干戈的在“屎一样的一大坨代码”里纠结半天了。
我们试过很多办法提升代码质量，包括强制code review、专门抽出时间重构、周会上的代码评审等等。每一种都或多或少的有一些效果，但最有效果的做法是引入自动化的代码风格检查工具，可以发现大部分代码细节问题，并且很容易量化，对于“质量”这种没有实感的东西，量化是能够让你持续投入很重要的一个方面。
而最终的收益不仅是开发效率的提升，更重要的是，一个不断进化的团队中的一员在看到烂代码时，感受到的是“如何解决这些问题”的挑战，而不是”这些代码再也不会好了“的无力感。
应该通过提升开发效率完成工作，而不是靠加班
有代码不断优化的基础，我们也很自然的把服务过渡到了微服务架构。微服务架构让我们能够更敏捷的工作，不再需要忍受单体架构带来的“一个巨大的黑盒”带来的不便，我们可以对性能做更细致的分析，对问题做更精确的定位，对技术选型也有更多自由。在此基础上建立起了持续部署系统终于把上线变成了一件日常工作，“等我5分钟，我review代码的时候发现个bug，上个线就去吃饭”。
我跟很多人谈起这个“5分钟上线”的时候，他们都觉着我是个不负责任的人，并且一遍又一遍的问我：“上线上出问题怎么办？”
问我这个问题的人一定是没有考虑过“复杂度”本身就是一个巨大的问题源，当代码足够简单、依赖足够清晰时，很多问题就自然的消失了。实际上，我们现在的上线次数从每周两次提高到了每天十几次之后，上线产生的问题已经几乎不存在了。
应该通过报警发现问题，而不是用户投诉
我去年用几天写了一个报警系统，团队又在此基础之上建立起了一套特别靠谱的报警服务，不再依靠“检查系统内部有没有问题”，而是站在用户的视角，依靠探测程序检查“用户在使用时是不是有问题”。
站在用户维度报警的好处是，只要有报警，那么就一定有问题。于是我们终于从每天轰炸式的报警短信中脱出身来，不再需要“按报警频率估计服务有没有问题”这种无用的工作，也不需要面对boss“怎么用户都投诉了你们还不知道”的尴尬问题。只要有报警，那么就需要处理；反过来，只要没报警，那么绝大部分用户使用也不会有问题，我可以放心的玩《守望先锋》而不用担心boss会突然来电话。
最终，有惊无险的，我们做到了服务全年无故障（虽然还有几天才过完今年，希望这不是一个flag……）。
应该通过技术解决性能问题，而不是堆机器
微博的访问量极大，做个方案动辄要支持百万并发、千亿数据，但奇葩的是公司又很穷总是买不起新服务器(--)，性能优化就变成了极其重要的工作。
我们今年做了不少应用的性能调优，把每个服务的性能指标都提升了几倍（还有几倍是留给明年的KPI的--）。性能调优是一件有挑战又有成就感的事情，而且比较有意思的地方是，无论程序员的水平是好是坏，总是有调优的空间。水平弱一些的同学可以调优业务代码和基本参数；好一些的优化架构和第三方组件；牛逼的可以深入jvm和内核原理。调优经验多了，总会有种“无论怎么优化也到不了头”的感觉。
另外，我们今年基于云服务、容器技术、调度系统、混合云编排系统、容量评估系统和自身的微服务架构体系，实现了公司成本部门老是念叨的的“按需扩缩容”功能，我们的直播互动系统也成为了微博内部首个按流量自动扩缩容的服务，达到了“5分钟完成无人值守自动扩缩容”的状态。在这个系统的帮助下，支撑微博直播互动服务的常备机器只有几台而已，参加技术大会看到有人谈直播架构时，总是莫名的有一种优越感……
应该做更多有挑战的事情，而不是一直重复自己的工作
今年我们承担了更多微博的业务，我们如今应该算是微博里少有的“后端服务一条龙”团队，一整年来我们都在整合和优化各种服务的架构和链路。从消息箱底层业务，到tcp连接服务，到收件箱后端服务，到直播互动服务，到微博视频服务，到文件存储服务等等，这一年做了不少对原服务进行重写和进行新架构设计的工作。
技术栈的多样化带来的是难以管理和重复性的工作，但是只要对不同的业务稍作抽象，那么就可以复用很多现有的基础设施，抽象和复用的实践多了，就可以称之为体系。今年我们对不同服务的各方面，比如架构、开发框架、运维、监控、报警等等方面做了抽象，建立起了一套体系，使我们不再受技术栈过于发散的困扰。
换句话说，团队一方面享受着大公司的技术积累，一方面又有各种新业务场景带来的技术挑战，这是挺难得的状态。
The Bad
就跟之前说的一样，今年本来想做一些更纯粹的研究工作，比如对操作系统内存模型完整的剖析，或者对性能分析能力的进一步提高，又或者再去qcon之类的技术大会露个脸，但是受限于身体状态，只好作罢。
前两年工作加班的比较猛，经常一搞就到凌晨5，6点。这一年也做了些调整，没再整到过后半夜，下了班就一溜小跑回家玩守……啊不是，回家休息。对团队小伙伴们的要求也是尽量提升效率，少加班。合理的作息和锻炼对于程序员很重要，”身体是革命的本钱“这句话诚不欺我。
今年还有个遗憾就是没能实现“三十岁前用自己写的语言写一个操作系统”的愿望。也忘了这是什么时候定下的“小目标”了，在如今，写个语言其实并不困难，编译器已经是很完善的技术了；写个操作系统也有一大堆从入门到xx系列。但难就难在真的去做，说到做到和觉着自己能做到还是两件事情，希望有机会还是自己动手做一做。
另一方面，对团队来说，还有很多想做但因为新业务太多而没有时间做的事情。比如弱网环境下的文件上传性能优化，微博私有通讯协议的优化，我们团队维护着的开源motan rpc框架对于微服务监控和调度能力的优化，还有最近微博越来越火的视频服务的后端转码服务、存储服务的性能优化，等等等等。这些只能期望来年搞定了。
The Ugly
程序员这个行业里的人大多数人不喜欢交际，我也一样。而实际工作中总有很多需要沟通的工作，而对于这部分工作实在是我的痛点。
而痛苦的来源主要来自于沟通时不在一个频段上，
比如我问”为什么没搞定“，而对方的回答是：“我不会啊”。
又或者我说“这么做的话会更合理”，而对方一直在强调：“我这么做能实现啊”。
再或者我说“这里的需求明显不合理”，而对方只有一句：“老板是这么要求的”。
无论如何，跟人沟通是一件痛苦的事情，尤其是跟与自己三观不合的人沟通更是如此。今年也没少经历过拍桌子大吼的场面。虽然不想承认，但是很多人并不是真的想把事情做好；有一些人的“好”跟你的“好”不是一个衡量体系；有些人虽然意愿很强，但他是笨蛋；当然，还有又懒又笨三观还跟你不一致的……
如何跟人打交道是我今年反思最多的问题之一，作为一个与世无争（？）的程序员，我希望尽量少跟人起冲突，默默的多写些代码，但又不想自己因为要避免冲突，变成跟他们一样又笨又懒的人，尝试了几次之后发现日剧里那些“靠热情就感染了身边的人”之类的桥段是骗人的（要么就是因为我没长一张男主角的脸），与其苦苦挣扎着期望别人某天突然改变，不如找些志同道合的人在身边。值得欣慰的是，今年招到的小伙伴都是能够认可我的三观，有意愿和能力把事情做的更好的人。

PS:如果你想成为一名优秀的架构师，

或者在工作中遇到瓶颈，想跳槽，碰到难题等等一系列问题，可以加我的架构师群：554355695

这里有专业的团队为你排忧解难，有最新的学习资源为你共享。