我是在 2014 年入職餓了么，從前端和 PHP 一直做到后端架構和團隊，從 2014 年到 2017 年陸續負責過公司客服、銷售、代理商、支付、清結算、訂單這些業務的產研與團隊;2018 年從業務研發團隊抽身，6 個人組起一個小組投身機器學習，試圖結合實際的業務場景通過技術改造業務;2019 年回歸到平臺(中臺)研發，負責交易、金融、營銷三個中臺的研發和團隊工作。

      基于我在餓了么4年和阿里巴巴 2 年研發經歷，從技術層面分享一些我的思考。

　　對開發同學而言，技術是立身之本，雖然往往面試造火箭入職擰螺絲，但不可否認的是，技術就是你從業的的基石。不管是基本的動手能力還是問題分析能力，包括你的思維邏輯乃至對事物認知的能力，技術思維都會時刻影響你。明顯的影響就是當你面對無數個問題的釘子時，技術是不是你順手的那把錘子。

　　技術上我比較關注的幾個層面：

　　基本功(語言、編碼這個層面，主要是動手能力)

　　大型分布式系統的實戰經驗(RPC、SOA、MySQL、Redis、MQ)

　　項目( DB 設計、API契約、DDD抽象、鏈路設計、項目風險把控)

　　穩定性(可用 & 資損)

　　1. 穩定性

　　穩定性是一個先有意識再有能力的事兒。記得在 2015 年年初，張雪峰加入餓了么擔任 CTO 之后，從他嘴里常聽到的一句話就是“研發要對生產環境有敬畏”。

　　2014年下半年，各方人馬開始殺入外賣市場，餓了么啟動百城計劃進行業務擴張，短時間內從10+城市覆蓋到100+城市，日訂單量也很快從10萬上漲到100萬。業務井噴的同時，技術還沒有做好足夠的準備。我印象中，2014年下半年幾乎每天中午交易量都有新高，但同時也伴隨著系統宕機、限流擴容、緊急調優、客服爆線、技術加班熬夜的問題。

　　我曾在新鄉的客服中心看到有的客服同學突然崩潰，耳機直接摔下來離開工位，因為每天會接收到大量用戶的來電責問，就在那一刻其實你才會清晰且直觀的感受到：你在編輯器的每一行代碼，你在服務器的每一次發布，會對現實世界很多活生生的人有直接的影響，你會突然意識到你的工作比你之前以為的要重要且有意義。

　　所謂研發要對生產環境有敬畏，就是你知道你的作品會對別人產生不好的影響，你會為不好的結果感到慚愧與內疚，這就產生了敬畏。應急處理有一個基本原則：“以業務影響小為主，優先恢復為核心目的，不要糾結手段和根因。”

　　別把你的懊悔、決心、對穩定性的思考、各種奇妙的idea以及執行力體現在事故復盤會上，系統的安全生產和火災一樣，事前才有意義。

　　2. 鏈路設計

　　大部分產研缺少全鏈路的視角，往往看到的是自己負責的點，但是對于一條線乃至整個面是看不到的，也沒有機會去思考這些，而對于一些大項目和長鏈路系統而言，這是致命的。

　　我的建議是，對你所負責的系統，它關鍵的上下游、核心業務的鏈路一定要熟悉，包括數據、接口(調用、功能、邏輯)、各種異常的處理和特殊的設計。能幫你達成這一目的的簡單的辦法就是畫圖、畫圖、畫圖!重要的結論說三遍，一定要自己能把系統的大圖畫出來，然后做到可以根據大圖隨意放大和縮小。放大到將鏈路畫到業務場景里，突出業務邏輯和上下游交互，縮小到某一次調用的處理邏輯大致是怎樣，數據是怎么變化。

　　經常畫圖，不用糾結形式和標準，重要的是形成自己理解系統的一個框架，一個自己的思維方式，需要的時候可以隨時拿出來用。

　　日常不管是聊需求還是做系統設計，習慣性的把圖畫出來，就達成了一半。剩下的一半就要看圖去想、去找問題。

　　3. 技術債務

　　永遠不要騙自己說，現在為了這個需求先挖一個坑，過一段時間再來填(重構 or 重做)。

　　技術債務和金融債務一樣，它必然存在，并且會像無賴一樣一直賴著，隔三差五會爆發一下。隨著時間的推移和業務的發展，你會發現架構越來越混亂，不同系統的領域邊界越來越模糊，系統和需求與組織關系的映射越來越復雜，服務內編碼風控越來越不一致，重復的輪子一個接一個隱蔽的出現。

　　“太忙了沒時間梳理哪些問題”、“改那些問題需要上下游一起改，費時費力，推不動”、“現在還沒出問題，而且正在整理了，別催”。這是我們經常會聽到的聲音。其實，技術同學多少都有點代碼潔癖，有很多問題不處理不是主觀的原因，而是客觀上因為精力、時間、ROI等因素，往往要等問題真的爆發后，大家才能狠下心去處理那些問題 。

　　我以前處理技術債務的思路，是要有一個檢查清單，我會定期的復盤所有的系統，并且結合自己團隊和其他團隊的事故去全量掃雷。系統本身是一個平衡的產物，是時間、功能、風險、未來可能性等幾個方向平衡的結果。所以技術債務對于研發同學的考驗，不在于你怎么在日常工作中保證系統技術債為0，而是你要評估清楚在有限的資源和時間下，哪些問題是刻不容緩的，哪些問題是可以往后放的。

　　很難想象一個沒有技術追求的團隊能開發出一個健壯的、可維護性好、可擴展性好的系統。相反，這種業務代碼的堆砌，從短期看也許是“較快”實現了業務需求，但是從長遠來看，這種爛系統的增加會極大地阻礙業務的發展，形成一個個的黑洞應用，而工程師被裹挾在業務需求和爛系統之間，疲于應對，心力交瘁。這種將就將導致系統腐化墮落，技術債越壘越高，丑陋的代碼瘋狂滋長，像腫瘤一樣消耗你所有的能量，還要你的命。

　　4. 警惕大項目

　　并不是所有人都有能力操盤大項目，也不是所有人都能夠平衡好交付壓力、上線質量、產品邏輯以及時間窗口，這是一個非常有挑戰的工作，需要純粹的技術能力之外的很多軟性能力來輔助，比如組織的溝通協作能力、向上要權要責的能力、平衡產品業務期望的的能力、突發情況應急轉變的能力等。越大的項目對于Owner的要求也越高，真能把大項目做好不怎么留大坑的少之又少。

　　大項目從啟動到立項所用的時間很多時候是遠超項目實際的開發周期的，項目的順利推進需要“妥協”，但項目的成功需要堅持。很多項目之所以失敗，是在做的過程中方方面面不斷妥協，做出來的東西已經遠離了開始想要的樣子。

　　5.持續學習才是根本

　　時代在持續發展和變化，現在正是波瀾壯闊的年代，在這樣的環境下，不管當前如何積累，都有可能隨著發展的變化在短時間跌落谷底。公司能發展，一定是在某一個時期內非常契合環境的要求，但隨著時間的變化，如果它的變化不能跟上來，那么也只會被時代拋棄。正所謂讓你成功的，終也將讓你失敗，比如柯達、諾基亞不能幸免，個體也難逃這樣的規律。

　　這樣的情況下，持續的學習和改變自身的能力才是研發同學、也是強的優勢。技術本身的日新月異要求你持續學習，同樣的習慣放射到各個領域上，才會慢慢的取長補短，優化自身，所以如果說研發同學需要什么，我認為持續的學習能力是關鍵的。

　　正如餓了么創始人汪淵在之前接受采訪時有一句話，讓我很難忘：重要的是選擇，困難的是堅持。

　　看了這個分享你有沒有收獲呢?要想成為一個的研發工程師基本的條件之一就是技術要好，學好技術當然是重中之重?；浨禝T培訓班，全力以赴助你圓夢，種一棵樹的時間是十年前，其次是現在，要想成為好的IT工程師，從現在開始來粵嵌學習吧!