阿里一年，聊聊我成長了什么，入職阿里的職業生涯感悟

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、tair
服務化有dubbo、跨語言可以用thrift
分布式任務調度可以考慮schedulex
搜索可以選es、solr
更高級一點圖片存儲可以用七牛、im可以用融云/環信、音視頻這塊聲網做得比較成熟，所有這些都提供了各個開發版本的sdk，接入簡單

只要你有的技術方面的需求，絕大多數業界已經有了成熟的解決方案了，根本不需要去專門自己搞一套。因此我認為輕易一定不要造輪子，如果一定要造輪子，那么請想清楚下面幾個問題：

你要做的事情是否當前已經有了類似解決方案？
如果有，那么你自己做的這一套東西和類似解決方案的差異點在哪里？假設不用你這套，基于已有的解決方案稍加改造是否就能達到目的？
如果沒有，那么為什么之前沒有？是你們公司這種場景是獨一無二的？還是這種場景對應的解決方案根本就是不可行的所以之前沒人去搞？

如果想清楚了這些問題，那么就去干吧。

關注軟技能的成長

這個點之前沒有寫到，深感遺憾，文章發表之后一直想要補充進來，因為關注軟技能的成長是我這一年除了技術思維轉變以外成長最大的地方。

我們是一個技術人沒錯，技術是我們每個人的立身之本，但是在工作中我們又不是單純與代碼打交道：

我們有PD，需要向他們了解需求的整體交互
我們有業務，需要全面了解需求的背景
技術團隊內部，我們需要相互之間溝通進度，交流技術方案、設計方案
技術團隊外部，我們需要對相互之間的交互方式，上下游進度不理想如何去推動
出了問題，我們需要知道對外應當怎么說，對內應該怎么做
有一個想法，應當如何以正確的方式去落地，而不是我有一個想法直接說也不說、討論也不討論干就完事了

凡此種種，都需要經歷和成長，曾經我也以為程序員只要把代碼寫好就好了，來了阿里，才深刻地感覺到寫代碼真的只是工作的一部分（可能50%？）而已。

我相信無論你在50個人的小公司還是在5000個人的大公司，身處3個人的技術團隊還是30個人的技術團隊，沒有一個人是單兵作戰的，這個行業對技術人的要求從單純的技術要求已經越來越往綜合素質去靠，所以，關注對自己軟技能的，相信無論對當下還是對未來，百利而無一害。

去提升看問題的高度

過去有太多人在我的公眾號或者博客下反饋了一個問題：在這個公司，整天做著增刪改查的工作，對自己一點都沒有提高。

對于這種看法，說難聽點就是四個字----目光短淺。我們看：

如果以普通的視角去看，那么一顆樹那也就只是一棵樹而已，但是如果跳脫出目前的視角，站在更高的角度去看，它其實是森林的一部分。你的主管并不是因為他是你的主管所以他就應該你比更高瞻遠矚，而是因為他看問題的高度比你更高、想得更遠、做得更深，所以才成為了你的主管。

把這個問題說得實際點：

假設今天你負責的是一個系統，那么你僅僅是把這個系統的基本原理搞懂了？還是可以把上下游有幾個系統、每個系統之間如何調用、依賴方式都理順？
假設今天你負責的是一塊業務，那么你僅僅把自己負責的功能點弄清楚了？還是你可以從最上游開始，到你負責的系統，再到最下游，都思考得非常透徹？

今天與其在抱怨沒有機會、抱怨公司對自己能力沒有提升，為什么不去思考機會為什么降臨在別人頭上不降臨在你頭上？為什么別人可以從小公司寫著一樣的增刪改查走向BAT而你年復一年還在小公司寫著增刪改查？當你真正能轉變自己的思維模式，跳脫出現在的圈子往更高一個層次去看問題、去提升自己，我相信總會有發光發熱的一天的。

同樣在阿里巴巴，馬老師思考自然、思考環保、思考人類的發展，你的主管思考團隊未來的方向和打法，我們在思考如何把某個客戶需求完整落地，這就是高度，你未必能想到馬老師想的，但是你可以對標層級高一點的人，一步一步嘗試往他們的高度去靠。

總而言之：眼界決定高度，多看、多想、多保持好奇心、多問幾個為什么，久而久之自然就邁上了一個新的臺階。