2018.5.31~2019.5.31，一段精彩的旅程，渡過了在阿里一年的時光，這段時光有快樂、有焦慮、有迷茫、更有思考，思考的是自己過去的種種不足、思考的是一些現在看來之前錯誤的想法、思考的是如何成爲一個更好的技術人，將這一些思考分享給看到這些文字的每個人，共勉。
一、應當如何面對線上的異常/故障
看起來毫無意義的一個問題，碰到線上異常/故障如何面對，排查解決了不就好了，但是這真的只是第一層。
最近在想“消防”這個詞語很有意思，它其實是兩層意思：
-
“消”是消除問題；
-
“防”是防止問題。
即“消防”這個詞語表達的意思應該是先消除問題再防止相同的問題再次發生。其實線上的異常/故障也是同樣的道理，我們應當先及時止血，把問題處理掉，然後深挖問題，探究根因，舉幾個例子：
-
假設是某段代碼的空指針異常導致的，那麼是否考慮加強Code Review，或者使用findbugs插件去自動掃描代碼中可能的異常？
-
假設是線上某個配置修改導致的，那麼是否今後變更的修改必須有人雙重檢查一遍纔可以修改？
-
假設是本地內存中某些值因爲系統重啓丟失導致的，那麼是否引入定時任務，定時把值寫入本地內存中？
-
假設是某段代碼邏輯沒測試到導致的，那麼是否可以反思總結爲什麼這段邏輯沒有測試到，未來的測試應該如何改進？
根據我過往的經驗，太多公司、太多團隊處理線上的問題僅僅滿足於把問題處理完就完事，忽略了對問題的覆盤，這對團隊/對公司的發展都是不利的。
二、什麼是真正的技術能力
之前加了幾個技術微信羣，看到很多技術朋友在興高采烈地討論各種源碼，spring源碼我徹底擼了一遍、最近深入學習了dubbo底層實現方式，當然曾經的我也是這樣的，記得學習volatile的時候一直挖到了volatile在硬件層面上的實現方式，但是這真的說明技術能力強嗎？從今天的思考去看這個問題，我認爲這更多反應的是一個人的學習能力、鑽研能力以及對技術的熱情，除此之外再體現不出太多其他東西了。
這個話題，可能是這一年思考的最多個的一個點，鑽研是好事，但是實際上大多時候的深入鑽研並不在實際工作中有用，且研究得越深，忘得越快，因爲研究得越深，那麼這個技術點關聯的技術點就越多，邊邊角角的忘了，核心的東西不容易串起來。那麼什麼是真正的技術能力，我畫一張圖概括一下：
簡而言之，技術能力 = 解決問題的能力，那麼同樣都在解決問題，大家之間的技術高低又有什麼區分呢？我認爲有以下幾個層次：
-
第一層級，解決當下問題；
-
第二層級，以優雅且可複用的方式解決當下問題；
-
第三層級，解決的問題不僅僅能滿足當下，還能滿足未來一段時間。
其實從這個角度上來看，不同的技術能力，在工作過程中區分度是很明顯的：
-
寫的代碼是否存在異常風險，多線程運行下是否存在線程安全問題，某段代碼是否會導致內存泄露；
-
寫的代碼是否優雅可複用，設計的框架是否足夠符合開閉原則，代碼結構層次是否清晰明瞭；
-
針對特定的場景，技術選型、庫表結構設計是否足夠合理，今天你設計的框架是隻能用一年，還是未來三年五年都可以持續使用；
-
來了一個大的需求，就比如做一個App的會員體系功能好了，是否可以在充分分析需求後，精確將需求劃分爲幾個特定的子模塊並梳理清楚模塊之間的關係。
越厲害的人，在代碼設計與開發過程中，越能看到想到一些別人看不到想不到的問題，這叫做高屋建瓴；當代碼運行出現問題的時候，有人1小時排查出問題，有人1分鐘發現問題，這叫做舉重若輕。
因此我認爲解決問題的能力纔是技術能力的真正體現，這一年對技術的探究我也從研究源碼更多的轉變去學習設計模式、去學習分佈式環境下各種NoSql的選型對比、去學習使用Lambda讓代碼更簡潔，往真正在實際工作中解決問題的方向去努力。
另外，拋開這個點，這兩天我在思考，還有一個體現技術能力的點，就是學習能力。現實中的全棧是很少的，互聯網這個行業的程序員的方向通常有幾類：
-
服務端；
-
前端；
-
移動端；
-
AI；
-
嵌入式；
-
大數據。
在同一類中，基礎知識、基本概念、思維方向是一致的，更多可能差異在開發工具、語言上，我精通Java，但是如果明天有一個需求，使用nodejs、scala、go更好，那麼是否可以快速學習、快速上手？甚至明天有一個需求需要寫前端代碼，是否可以快速開發、無bug上線？
所以，解決問題的能力 + 學習能力，是我認爲真正的技術能力，不過說到底，學習能力某種程度上也只是爲了解決問題而已。
三、不要造輪子
曾幾何時，當我們看着github上這麼多優秀的源代碼的時候，默默立誓，這輩子我一定要寫出一個牛逼的框架，開源在網上。
對於一些複雜條件的報警，比如我們上邊提到的失敗率和流量波動，應該如何實現呢？
很多對技術有追求的朋友，進入一家公司可能時時刻刻在尋找機會去做一些自己造輪子的事情，但是就如同前面所說的，衡量真正好技術的標準就是能否實實在在地解決問題，自己造輪子風險高、週期長，且需要長時間的驗證、排坑才能達到比較好的效果。
隨便舉幾個例子，在互聯網發展的今天：
-
數據庫連接池有dbcp、c3p0、druid；
-
本地緩存有ehcache、要用中心緩存有redis、tail；
-
服務化有dubbo、跨語言可以用thrift；
-
分佈式任務調度可以考慮schedulex；
-
搜索可以選es、solr；
只要你有的技術方面的需求，絕大多數業界已經有了成熟的解決方案了，根本不需要去專門自己搞一套。因此我認爲輕易一定不要造輪子，如果一定要造輪子，那麼請想清楚下面幾個問題：
-
你要做的事情是否當前已經有了類似解決方案？
-
如果有，那麼你自己做的這一套東西和類似解決方案的差異點在哪裏？假設不用你這套，基於已有的解決方案稍加改造是否就能達到目的？
-
如果沒有，那麼爲什麼之前沒有？是你們公司這種場景是獨一無二的？還是這種場景對應的解決方案根本就是不可行的所以之前沒人去搞？
如果想清楚了這些問題，那麼就去幹吧。
四、去提升看問題的高度
過去有太多人在我的公衆號或者博客下反饋了一個問題：在這個公司，整天做着增刪改查的工作，對自己一點都沒有提高。
對於這種看法，說難聽點就是四個字——目光短淺。我們看：
如果以普通的視角去看，那麼一顆樹那也就只是一棵樹而已，但是如果跳脫出目前的視角，站在更高的角度去看，它其實是森林的一部分。你的主管並不是因爲他是你的主管所以他就應該你比更高瞻遠矚，而是因爲他看問題的高度比你更高、想得更遠、做得更深，所以才成爲了你的主管。
把這個問題說得實際點：
-
假設今天你負責的是一個系統，那麼你僅僅是把這個系統的基本原理搞懂了？還是可以把上下游有幾個系統、每個系統之間如何調用、依賴方式都理順？
-
假設今天你負責的是一塊業務，那麼你僅僅把自己負責的功能點弄清楚了？還是你可以從最上游開始，到你負責的系統，再到最下游，都思考得非常透徹？
今天與其在抱怨沒有機會、抱怨公司對自己能力沒有提升，爲什麼不去思考機會爲什麼降臨在別人頭上不降臨在你頭上？爲什麼別人可以從小公司寫着一樣的增刪改查走向BAT而你年復一年還在小公司寫着增刪改查？當你真正能轉變自己的思維模式，跳脫出現在的圈子往更高一個層次去看問題、去提升自己，我相信總會有發光發熱的一天的。
同樣在阿里巴巴，馬老師思考自然、思考環保、思考人類的發展，你的主管思考團隊未來的方向和打法，我們在思考如何把某個客戶需求完整落地，這就是高度，你未必能想到馬老師想的，但是你對標層級高一點的人，一步一步嘗試往他們的高度去靠。
總而言之：眼界決定高度，多看、多想、多保持好奇心、多問幾個爲什麼，久而久之自然就邁上了一個新的臺階。
五、學會總結
需求、項目的覆盤是非常重要的一部分內容，然而我之前見過的太多團隊、太多Leader，只顧着一個迭代接着一個迭代，一個版本接着一個版本，只滿足於把需求做好，而忽略了總結的重要性。
我認爲大到項目、小到需求，如果在完成之後缺乏總結那麼某種程度上來說是失敗的，可以總結的點非常多：
-
通過這個項目/需求，是否吃透了某一塊業務，搞懂了來龍去脈；
-
通過這個項目/需求，是否充分理解了公司某個技術框架/基礎組件的用法；
-
在整個項目的設計上，有哪些做的不好的地方；
-
在整個項目的開發（針對程序員而言），是否踩了坑，犯了低級的錯誤；
-
在整個項目的進度把控上、人員安排上、上下游協調上，是否存在不足之處；
-
經歷了某次大促的值班，是否對可以熟練使用公司的監控工具，遇到突發事件，是否快速有效地進行了解決。
任何工作一定對個人都是有提升的，但是不會總結的人，在每個項目/需求中成長的東西都是散的，久而久之就忘了。通過充分的總結之後，犯過的錯誤我們不會二次再犯，理清楚的業務的來龍去脈銘記在心，對自己是一種提升，分享給別人對別人也是很大的幫助。
失敗者失敗的原因各有不同，成功者的做事方式總是相似的，從宏觀角度去看，我認爲總結就是成功者之所以能成功，很重要一個原因。
作者：五月的倉頡
來源：五月的倉頡（ID：gh_6b7a3f664e7d）