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

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而你年復一年還在小公司寫着增刪改查？當你真正能轉變本身的思惟模式，跳脫出如今的圈子往更高一個層次去看問題、去提高本身，我相信總會有發光發熱的一天的。

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

總而言之：眼界決定高度，多看、多想、多保持好奇心、多問幾個爲何，長此以往天然就邁上了一個新的臺階。

學會總結

需求、項目的覆盤是很是重要的一部份內容，然而我以前見過的太多團隊、太多Leader，只顧着一個迭代接着一個迭代，一個版本接着一個版本，只知足於把需求作好，而忽略了總結的重要性。

我認爲大到項目、小到需求，若是在完成以後缺少總結那麼某種程度上來講是失敗的，能夠總結的點很是多：

• 經過這個項目/需求，是否吃透了某一塊業務，搞懂了前因後果
• 經過這個項目/需求，是否充分理解了公司某個技術框架/基礎組件的用法
• 在整個項目的設計上，有哪些作的很差的地方
• 在整個項目的開發（針對程序員而言），是否踩了坑，犯了低級的錯誤
• 在整個項目的進度把控上、人員安排上、上下游協調上，是否存在不足之處
• 經歷了某次大促的值班，是否對能夠熟練使用公司的監控工具，遇到突發事件，是否快速有效地進行了解決

任何工做必定對我的都是有提高的，可是不會總結的人，在每一個項目/需求中成長的東西都是散的，長此以往就忘了。經過充分的總結以後，犯過的錯誤咱們不會二次再犯，理清楚的業務的前因後果銘記在心，對本身是一種提高，分享給別人對別人也是很大的幫助。

失敗者失敗的緣由各有不一樣，成功者的作事方式老是類似的，從宏觀角度去看，我認爲總結就是成功者之因此能成功，很重要一個緣由。

選擇大於努力

好吧，我認可調皮了，可是這一段我也是很真誠的！

人，努力是最重要的，可是選擇也很是重要。有能力是很是好的，有能力的同時，一個好的Leader、一個好的團隊將會讓你在平時工做中感到無比舒心，將會讓你有家通常的溫暖，更能將你的能力最大化！

菜鳥國際物流技術團隊就是這麼一個團隊！

最後，很是重要的一點：不要懼怕面試。經過面試才能發現不足，才能知道將來在技術道路上還須要在哪些方面進行提升，在面試的結尾，你也能夠詢問面試官本身有什麼不足，面試官必定會給到你最誠懇的建議！

結合這篇文章和本身的總結：

一、學習能力影響技能，探索能力影響高度；

二、重複造輪子 = 時間成本浪費;

三、知識固化很重要(項目、文檔、博客、總結...)；

四、把持自主選擇權(大多數狀況下莫得選)；

五、環境很重要

阿里騰訊Android開發十年，到中年危機就只剩下這套移動架構體系了！