2018.5.31~2019.5.31，一段精彩的旅程，渡過了在阿里一年的時光，這段時光有快樂、有焦慮、有迷茫、更有思考。

[[270553]]

圖片來自 Pexels

思考的是自己過去的種種不足、思考的是一些現在看來之前錯誤的想法、思考的是如何成為一個更好的技術人，將這一些思考分享給看到這些文字的每個人，共勉。

應當如何面對線上的異常/故障?

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

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

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

即“消防”這個詞語表達的意思應該是先消除問題再防止相同的問題再次發生。

其實線上的異常/故障也是同樣的道理，我們應當先及時止血，把問題處理掉，然后深挖問題，探究根因。

舉幾個例子：

• 假設是某段代碼的空指針異常導致的，那么是否考慮加強 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。
• 分布式任務調度：可以考慮 SchedulerX。
• 搜索可以選：ES、Solr。
• 更高級一點圖片存儲：可以用七牛、IM 可以用融云/環信、音視頻這塊聲網做得比較成熟，所有這些都提供了各個開發版本的 SDK，接入簡單。

只要你有的技術方面的需求，絕大多數業界已經有了成熟的解決方案了，根本不需要去專門自己搞一套。

因此我認為輕易一定不要造輪子，如果一定要造輪子，那么請想清楚下面幾個問題：

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

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

去提升看問題的高度

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

對于這種看法，說難聽點就是四個字——目光短淺。我們看：也可以通過字典方式傳參，MGJRouter 提供了帶有字典參數的方法，這樣就可以傳遞非字符串之外的其他類型參數，例如對象類型參數。

如果以普通的視角去看，那么一顆樹那也就只是一棵樹而已，但是如果跳脫出目前的視角，站在更高的角度去看，它其實是森林的一部分。

你的主管并不是因為他是你的主管所以他就應該比你更高瞻遠矚，而是因為他看問題的高度比你更高、想得更遠、做得更深，所以才成為了你的主管。

把這個問題說得實際點：

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

今天與其在抱怨沒有機會、抱怨公司對自己能力沒有提升，為什么不去思考機會為什么降臨在別人頭上不降臨在你頭上?

為什么別人可以從小公司寫著一樣的增刪改查走向 BAT，而你年復一年還在小公司寫著增刪改查?

當你真正能轉變自己的思維模式，跳脫出現在的圈子往更高一個層次去看問題、去提升自己，我相信總會有發光發熱的一天的。

同樣在阿里巴巴，馬老師思考自然、思考環保、思考人類的發展，你的主管思考團隊未來的方向和打法。

我們在思考如何把某個客戶需求完整落地，這就是高度，你未必能想到馬老師想的，但是你對標層級高一點的人，一步一步嘗試往他們的高度去靠。

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

學會總結

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

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

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

任何工作一定對個人都是有提升的，但是不會總結的人，在每個項目/需求中成長的東西都是散的，久而久之就忘了。

通過充分的總結之后，犯過的錯誤我們不會二次再犯，理清楚的業務的來龍去脈銘記在心，對自己是一種提升，分享給別人對別人也是很大的幫助。

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

作者：五月的倉頡

簡介：目前就職于阿里巴巴-菜鳥網絡-國際物流技術部，從事后臺開發。