2018.5.31~2019.5.31，一段精彩的旅程，渡過了在阿里一年的時光，這段時光有快樂、有焦慮、有迷茫、更有思考，思考的是自己過去的種種不足、思考的是一些現(xiàn)在看來之前錯誤的想法、思考的是如何成為一個更好的技術(shù)人，將這一些思考分享給看到這些文字的每個人，共勉。

應(yīng)當如何面對線上的異常/故障

看起來毫無意義的一個問題，碰到線上異常/故障如何面對，排查解決了不就好了，但是這真的只是第一層。

最近在想“消防”這個詞語很有意思，它其實是兩層意思：

• “消”是消除問題
• “防”是防止問題

即“消防”這個詞語表達的意思應(yīng)該是先消除問題再防止相同的問題再次發(fā)生。其實線上的異常/故障也是同樣的道理，我們應(yīng)當先及時止血，把問題處理掉，然后深挖問題，探究根因，舉幾個例子：

• 假設(shè)是某段代碼的空指針異常導致的，那么是否考慮加強Code Review，或者使用findbugs插件去自動掃描代碼中可能的異常？
• 假設(shè)是線上某個配置修改導致的，那么是否今后變更的修改必須有人雙重檢查一遍才可以修改？
• 假設(shè)是本地內(nèi)存中某些值因為系統(tǒng)重啟丟失導致的，那么是否引入定時任務(wù)，定時把值寫入本地內(nèi)存中？
• 假設(shè)是某段代碼邏輯沒測試到導致的，那么是否可以反思總結(jié)為什么這段邏輯沒有測試到，未來的測試應(yīng)該如何改進？

根據(jù)我過往的經(jīng)驗，太多公司、太多團隊處理線上的問題僅僅滿足于把問題處理完就完事，忽略了對問題的復(fù)盤，這對團隊/對公司的發(fā)展都是不利的。

什么是真正的技術(shù)能力

之前加了幾個技術(shù)微信群，看到很多技術(shù)朋友在興高采烈地討論各種源碼，spring源碼我徹底擼了一遍、最近深入學習了dubbo底層實現(xiàn)方式，當然曾經(jīng)的我也是這樣的，記得學習volatile的時候一直挖到了volatile在硬件層面上的實現(xiàn)方式，但是這真的說明技術(shù)能力強嗎？從今天的思考去看這個問題，我認為這更多反應(yīng)的是一個人的學習能力、鉆研能力以及對技術(shù)的熱情，除此之外再體現(xiàn)不出太多其他東西了。

這個話題，可能是這一年思考的最多個的一個點，鉆研是好事，但是實際上大多時候的深入鉆研并不在實際工作中有用，且研究得越深，忘得越快，因為研究得越深，那么這個技術(shù)點關(guān)聯(lián)的技術(shù)點就越多，邊邊角角的忘了，核心的東西不容易串起來。那么什么是真正的技術(shù)能力，我畫一張圖概括一下：

簡而言之，技術(shù)能力 = 解決問題的能力，那么同樣都在解決問題，大家之間的技術(shù)高低又有什么區(qū)分呢？我認為有以下幾個層次：

• 第一層級，解決當下問題
• 第二層級，以優(yōu)雅且可復(fù)用的方式解決當下問題
• 第三層級，解決的問題不僅僅能滿足當下，還能滿足未來一段時間

其實從這個角度上來看，不同的技術(shù)能力，在工作過程中區(qū)分度是很明顯的：

• 寫的代碼是否存在異常風險，多線程運行下是否存在線程安全問題，某段代碼是否會導致內(nèi)存泄露
• 寫的代碼是否優(yōu)雅可復(fù)用，設(shè)計的框架是否足夠符合開閉原則，代碼結(jié)構(gòu)層次是否清晰明了
• 針對特定的場景，技術(shù)選型、庫表結(jié)構(gòu)設(shè)計是否足夠合理，今天你設(shè)計的框架是只能用一年，還是未來三年五年都可以持續(xù)使用
• 來了一個大的需求，就比如做一個App的會員體系功能好了，是否可以在充分分析需求后，精確將需求劃分為幾個特定的子模塊并梳理清楚模塊之間的關(guān)系

越厲害的人，在代碼設(shè)計與開發(fā)過程中，越能看到想到一些別人看不到想不到的問題，這叫做高屋建瓴；當代碼運行出現(xiàn)問題的時候，有人1小時排查出問題，有人1分鐘發(fā)現(xiàn)問題，這叫做舉重若輕。

因此我認為解決問題的能力才是技術(shù)能力的真正體現(xiàn)，這一年對技術(shù)的探究我也從研究源碼更多的轉(zhuǎn)變?nèi)W習設(shè)計模式、去學習分布式環(huán)境下各種NoSql的選型對比、去學習使用Lambda讓代碼更簡潔，往真正在實際工作中解決問題的方向去努力。

另外，拋開這個點，這兩天我在思考，還有一個體現(xiàn)技術(shù)能力的點，就是學習能力?，F(xiàn)實中的全棧是很少的，互聯(lián)網(wǎng)這個行業(yè)的程序員的方向通常有幾類：

• 服務(wù)端
• 前端
• 移動端
• AI
• 嵌入式
• 大數(shù)據(jù)

在同一類中，基礎(chǔ)知識、基本概念、思維方向是一致的，更多可能差異在開發(fā)工具、語言上，我精通Java，但是如果明天有一個需求，使用nodejs、scala、go更好，那么是否可以快速學習、快速上手？甚至明天有一個需求需要寫前端代碼，是否可以快速開發(fā)、無bug上線？

所以，解決問題的能力 + 學習能力，是我認為真正的技術(shù)能力，不過說到底，學習能力某種程度上也只是為了解決問題而已。

不要輕易造輪子

曾幾何時，當我們看著github上這么多優(yōu)秀的源代碼的時候，默默立誓，這輩子我一定要寫出一個牛逼的框架，開源在網(wǎng)上。

曾幾何時，公司招聘的時候，技術(shù)負責人激情滿滿地介紹著公司內(nèi)部自研了多少系統(tǒng)并在線上投入使用。

很多對技術(shù)有追求的朋友，進入一家公司可能時時刻刻在尋找機會去做一些自己造輪子的事情，但是就如同前面所說的，衡量真正好技術(shù)的標準就是能否實實在在地解決問題，自己造輪子風險高、周期長，且需要長時間的驗證、排坑才能達到比較好的效果。

隨便舉幾個例子，在互聯(lián)網(wǎng)發(fā)展的今天：

• 數(shù)據(jù)庫連接池有dbcp、c3p0、druid
• 本地緩存有ehcache、要用中心緩存有redis、tair
• 服務(wù)化有dubbo、跨語言可以用thrift
• 分布式任務(wù)調(diào)度可以考慮schedulex
• 搜索可以選es、solr
• 更高級一點圖片存儲可以用七牛、im可以用融云/環(huán)信、音視頻這塊聲網(wǎng)做得比較成熟，所有這些都提供了各個開發(fā)版本的sdk，接入簡單

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

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

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

關(guān)注軟技能的成長

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

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

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

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

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

去提升看問題的高度

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

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

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

把這個問題說得實際點：

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

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

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

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

學會總結(jié)

需求、項目的復(fù)盤是非常重要的一部分內(nèi)容，然而我之前見過的太多團隊、太多Leader，只顧著一個迭代接著一個迭代，一個版本接著一個版本，只滿足于把需求做好，而忽略了總結(jié)的重要性。

我認為大到項目、小到需求，如果在完成之后缺乏總結(jié)那么某種程度上來說是失敗的，可以總結(jié)的點非常多：

• 通過這個項目/需求，是否吃透了某一塊業(yè)務(wù)，搞懂了來龍去脈
• 通過這個項目/需求，是否充分理解了公司某個技術(shù)框架/基礎(chǔ)組件的用法
• 在整個項目的設(shè)計上，有哪些做的不好的地方
• 在整個項目的開發(fā)（針對程序員而言），是否踩了坑，犯了低級的錯誤
• 在整個項目的進度把控上、人員安排上、上下游協(xié)調(diào)上，是否存在不足之處
• 經(jīng)歷了某次大促的值班，是否對可以熟練使用公司的監(jiān)控工具，遇到突發(fā)事件，是否快速有效地進行了解決

任何工作一定對個人都是有提升的，但是不會總結(jié)的人，在每個項目/需求中成長的東西都是散的，久而久之就忘了。通過充分的總結(jié)之后，犯過的錯誤我們不會二次再犯，理清楚的業(yè)務(wù)的來龍去脈銘記在心，對自己是一種提升，分享給別人對別人也是很大的幫助。

失敗者失敗的原因各有不同，成功者的做事方式總是相似的，從宏觀角度去看，我認為總結(jié)就是成功者之所以能成功，很重要一個原因。

選擇大于努力

好吧，我承認調(diào)皮了，但是這一段我也是很真誠的！

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

菜鳥國際物流技術(shù)團隊就是這么一個團隊！

最后，非常重要的一點：不要害怕面試。通過面試才能發(fā)現(xiàn)不足，才能知道未來在技術(shù)道路上還需要在哪些方面進行提高，在面試的結(jié)尾，你也可以詢問面試官自己有什么不足，面試官一定會給到你最誠懇的建議！

結(jié)合這篇文章和自己的總結(jié)：

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

2、重復(fù)造輪子 = 時間成本浪費;

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

4、把持自主選擇權(quán)(大多數(shù)情況下莫得選)；

5、環(huán)境很重要

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

轉(zhuǎn)載于:https://juejin.im/post/5d01c558e51d45777540fd95

總結(jié)

以上是生活随笔為你收集整理的阿里一年，聊聊我成长了什么，入职阿里的职业生涯感悟的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。