眼看著又一年結束，想想今年過的還真是快，上個畫面還是去年年末各種處理故障的場景，一眨眼一年就過去了。既然過了一年，還是得留下些思考和展望，否則就有些太無趣了。
還是套用那個老的不能再老的梗吧，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

這里有專業的團隊為你排憂解難，有最新的學習資源為你共享。