寫給工程師的十條精進原則

引言

時間回到8年前，我人生中第一份實習的工做，是在某互聯網公司的無線搜索部作一個C++工程師。當時的我可謂意氣風發，想要大幹一場，結果第一次上線就寫了人生中第一個Casestudy。因爲對部署環境的不瞭解，把SVN庫裏的配置文件錯誤地發到線上，而且上完線就去吃晚飯了，等吃飯回來發現師傅在焦頭爛額地回滾配置。那次故障形成了一個核心服務20分鐘不可用，影響了幾百萬的用戶。這僅僅是一個開始，在後來半年的時間裏，我幾乎把全部職場新人可能犯的錯誤都犯了個遍。架構師讓我調研一個抓取性能提高方案，我悶頭搞了兩週，也沒有得出任何結論；原本安排好的開發計劃，因爲我臨時要回去寫論文，搞得經理措手不及；參加項目座談會，全程「打醬油」......那段時間，本身也很苦惱，幾乎天天晚上11點多才走，很累很辛苦，但依然拿不到想要的結果。

8年過去了，本身從一個職場小白逐步成長爲一名技術Leader。我發現團隊中的不少同窗在不停地重複犯着本身當年相似的錯誤。他們並非不努力，究竟是哪裏出了問題？通過一段時間的觀察與思考後，我想我找到了答案。那就是：咱們大多數同窗在工做中缺少原則的指導。原則，猶如指引行動的「燈塔」，它鏈接着咱們的價值觀與行動。不久前，橋水基金創始人雷·達里奧在《原則》一書中所傳達的理念，引爆了朋友圈。每一個人都應該有本身的原則，當咱們須要做出選擇時，必定要堅持以原則爲中心。可是在現實生活中，咱們每每缺乏對原則的總結，對於不少人來講這是一門「只可意會不可言傳」的玄學，是屬於老司機的祕密，其實否則。

「追求卓越」是美團的價值觀。做爲一名技術人員，咱們應該如何踐行呢？本文總結了十條精進原則，但願可以給你們帶來一些啓發，更好地指導咱們的行動。

原則一：Owner意識

「Owner意識」主要體如今兩個層面：一是認真負責的態度，二是積極主動的精神。

認真負責是工做的底線。首先，要對咱們交付的結果負責。項目中每個設計文檔、每一行代碼都須要認真完成，要對它的質量負責。若是設計文檔邏輯混亂，代碼沒有註釋，測試時發現一堆Bug，影響的不只僅是RD的工程交付質量，還會對協同工做的RD、QA、PM等產生很差的影響。長此以往，團隊的總體交付質量、工做效率也會逐步降低，甚至會致使團隊成員之間產生不信任感。其次，咱們要對開發的系統負責。系統的架構是否須要改進，接口文檔是否完善，日誌是否完整，數據庫是否須要擴容，緩存空間夠不夠等等，這些都是須要落地的事情。做爲系統Owner，請必定要認真履行。

積極主動是「Owner意識」更高一級的要求。RD天天要面對大量的工做，並且不少並不在計劃內，這就須要具有一種積極主動的精神。例如咱們天天可能會面對大量的技術諮詢，若是客戶提出的問題很長時間得不到迴應的話，就會帶來很差的客戶體驗。不少同窗說忙於本身的工做沒有時間處理，有同窗以爲這件事不是很重要，也有不少同窗是看到了，可是不知道怎麼回答，更有甚者，看到了乾脆裝沒看見。這些都是缺少Owner意識的體現。正確的作法是積極主動地推進問題的解決，若是時間沒法排開或者不知道如何解決，能夠直接將問題反饋給能解決的同窗。積極主動還能夠表如今更多方面。好比不少同窗會自發地梳理負責服務的現狀，根據接口在性能方面暴露的問題提出改進意見並持續推進解決；也有同窗在跨團隊溝通中主動承擔起主R的角色，積極發現問題、暴露問題，推進合做團隊的進度，保證項目順利推動。這些同窗無一不是團隊的中堅力量。因此，咱們在作好本身分內工做的同時，也應該積極主動地投入到「份外」的工做中去。一分耕耘一分收穫，不要給本身設限，努力成爲一個更加優秀的人。

原則二：時間觀念

相信你們都有時間觀念，可是真正能執行到位的可能並無那麼多。互聯網是一個快速發展的行業，RD的研發效率是一個公司硬實力的重要體現。項目的定期交付是一項很重要的執行能力，在很大程度上決定着領導和同事對本身靠譜程度的評價。你們可能會問：難度幾乎相同的項目，爲何有的同窗常常Delay，而有的同窗每次都能按時上線？一個很重要的緣由，就是這些按時交付的同窗每每具有以下兩個特質：作事有計劃，工做分主次。

工做安排要有計劃性。一般，RD在設計評審以後就能預估出精確的開發時間，進而再合理地安排開發、聯調、測試計劃。若是是項目負責人，那麼就會涉及協調FE、QA、PM等多個工種的同窗共同完成工做。凡事預則立，不預則廢。在計劃制定過程當中，要儘量把每一項拆細一點（至少到pd粒度）。事實證實，粒度越細，計劃就越精準，實際開發時間與計劃之間的偏差就會越小。此外，務必要規定明確的可檢查的產出，並在計劃中設置一些關鍵的時間點進行覈對。無數血淋淋的事實告訴咱們，不少項目延期都是由於在一些關鍵交付點上雙方存在分歧形成的。例如後臺RD的接口文檔計劃在週五提供，FE認爲是週五上午，而RD認爲是週五下班前提交，無形中會給排期帶來了1pd的偏差。因此，咱們要作到計劃粒度足夠細，關鍵時間點要可檢查。

工做安排要分清楚主次。咱們天天要面對不少的事情，要學會分辨這些工做的主次。能夠嘗試使用「艾森豪威爾法則」（四象限法則），把工做按照重要、緊急程度分紅四象限。優先作重要緊急的事情；重要不緊急的事情能夠暫緩作，可是要持續推動；緊急不重要的事情能夠酌情委託給最合適的人作；不重要不緊急的事情能夠考慮不作。不少項目沒法定期交付的緣由，都是由於執行人分不清主次。好比在開發中須要使用到ES，一些不熟悉ES的同窗可能想系統性地學習一下這方面的知識，就會一頭扎進ES的汪洋中。最後才發現，本來一天就能完成的工做被嚴重拖後。實際工做中，咱們應當避免這種「本末倒置」的工做方式。在本例中，「系統性地學習ES」是一件重要但不緊急的事情。要學會分辨出這些干擾的工做項，保證重要緊急的事情可以按時交付。

原則三：以終爲始

「以終爲始」（Begin With The End In Mind），是史蒂芬·柯維在《高效能人士的七個習慣》中提到的一個習慣。它是以全部事物都通過兩次創造的原則（第一次爲心智上的創造，第二次爲實際的創造）爲基礎的。直觀的表達就是：先想清楚目標，而後努力實現。

在工做中，不少RD每每只是埋頭走路，不多擡頭看天。每次季度總結的時候，羅列了不少項目，付出不少努力。可是具體這些項目取得了哪些收益，對業務有哪些提高，卻很難說出來。這就說明在工做中並無遵照「以終爲始」這一原則。此外，不少同窗在作需求的過程當中，對於目標與收益關注不夠，系統上線以後，也沒有持續地跟進使用效果。這一點在技術優化項目中體現得尤其明顯。例如在一個接口性能優化的項目中，通過RD的努力優化，系統TP99縮短了60%，支持QPS提高了2倍。可是系統到底須要優化到什麼程度呢？是否是縮短60%，提高2倍就能知足需求呢？在優化以前，不少同窗經常忘記設置一個預設的目標（TP99小於多少，支持QPS大於多少）。咱們必須清楚，優化必定是有緣由的，好比預期某節假日流量會暴增或者某接口超時比例太高，若是不進行優化，系統可能會存在宕機風險。解決特定的問題纔是技術優化的最終目的，因此要根據問題設定目標，再進行優化。

「以終爲始」，這一原則還能夠做用於咱們的學習中。不少同窗看過不少技術文章，可是老是感受本身仍然一無所知。很重要的一個緣由，就是沒有帶着目標去學習。在這個信息爆炸的時代，若是隻是碎片化地接收各個公衆號推送的文章，效果幾乎能夠忽略不計。在學習以前，咱們必定要問本身，此次學習的目標是什麼？是想把Redis的持久化原理搞清楚，仍是把Redis的主從同步機制弄明白，亦或是想學習整個Redis Cluster的架構體系。若是咱們可以帶着問題與目標，再進行相關的資料蒐集與學習，就會事半功倍。這種學習模式的效果會比碎片化閱讀好不少。

原則四：閉環思惟

你是否遇到過這樣的場景：參加了一個設計（或需求）評審，你們興致勃勃地提了不少合理的意見，等到再次評審的時候，卻發現第一次提的不少問題都沒有獲得改進，不少討論過的問題須要從頭再開始討論。這種狀況就是一種典型的工做不閉環。

以前看過一句話：一我的是否靠譜，就看他可否作到凡事有交代，件件有着落，事事有迴音。這就是閉環思惟的重要性。它強調的是一種即時反饋閉環，若是別人給咱們分配了一個任務，無論完成的結果如何，必定要在規定的時間內給出明確的反饋。例如在跨部門的溝通會議中，雖然各方達成了一致，會議發起者已經將最終的記錄周知你們。可是，到這一步其實並無完成真正的閉環，在落地執行過程當中極可能還存在一些潛在的問題。例如，會議紀要是否經各方仔細覈對並確認過？會議中明確的To Do進展是什麼？完成結果有沒有Check的機制？若是這些沒有作到的話，就會陷入「溝通-發現問題-再溝通-再發現問題」的惡性循環中。真正的閉環，要求咱們對工做中的事情都可以養成良好的思惟習慣，溝通要有結論，通知要有反饋，To Do要有驗收。

「閉環思惟」還要求可以按期主動進行階段性的反饋。剛參加工做時，我接了一個工期爲兩個月的項目。整個項目須要獨自完成，本身天天按照計劃，有條不紊地進行開發。大概過了兩週以後，Leader詢問項目進度，雖然我已經跟他說沒問題。然而，Leader告訴我，由於我天天對着電腦也不說話，讓他內心很沒底。這時，我才意識到一個很重要的問題，我跟Leader之間存在信息不對稱。從那之後，我就時不時得跟他彙報一下進度，哪怕就只有簡短的一句話，也能夠明顯感受，他對個人信心增長了不少。特別是我作Leader以後，對這種閉環反饋的理解，就更加深入了。從Leader的角度看，其實只是想知道項目是否在正常推動，是否遇到問題須要他協助解決。

原則五：保持敬畏

「君子之心，常懷敬畏」，保持敬畏之心可以讓咱們少犯錯誤。在工做中存在各類各樣的規範，例如代碼規範、設計規範、上線規範等等。咱們必須明白，這些規範的制定必定是基於某些客觀緣由的，它們都是歷史上無數Case積累而來的經驗。團隊裏的每個成員都應該學習並嚴格遵照，這一點對於新人尤爲重要。

當咱們進入到一個新的團隊，請先暫時忘掉以前的習慣，要儘快學習團隊既有的規範，而且讓本身與團隊保持一致。以編碼風格爲例，不少同窗每每習慣於本身以前的代碼寫做風格，在作新公司第一個項目時，也按照本身的習慣進行變量、包的命名等等。結果在代碼Review過程當中，被提了不少修改意見，不得不返工重寫，得不償失。若是可以保持敬畏之心，提早了解編碼規範，這種問題徹底能夠避免。相似的問題，還包括對上線流程不瞭解，對回滾操做不熟悉，對SRE線上變動過程不瞭解等等。除了這些顯而易見的規範，還有一些約定俗成的規則。我的建議是：若是有事情拿不許，不妨多問問其餘同事，不要憑本身的感受作事情。

保持敬畏之心並不意味着要「因循守舊」。在咱們充分了解這些規範和約定以後，若是以爲存在不妥之處，能夠跟全組同窗討論，是否採納新的建議，而後及時去更新迭代。其實，讓規範與約定與時俱進，也是另外一種形式的敬畏。

原則六：事不過二

「事不過二」，是咱們團隊一向堅持的原則，它能夠解讀爲兩層含義。

一層含義是**「全部的評審與問題討論，不要超過兩次」**。之因此有這樣的要求，是由於咱們發現，不少RD都把時間花費在一些無休止的評審與問題討論中，真正投入到實際開發中的時間反而不多。在實際工做場景中，咱們常常會遇到一些不是很成熟的需求評審。這些需求文檔，要麼是背景與目標含糊不清，要麼是產品方案描述不夠細化，或者存在歧義。RD與PM被迫反覆進行討論，我曾經遇到過一個需求評審，進行了三次還被打回。一樣的問題，在設計評審中也家常便飯。方案當然須要通過反覆的討論，可是若是遲遲不能達成一致，就會耗費不少RD與PM的寶貴時間，這就與提高研發效率的理念背道而馳。所以，咱們團隊規定：**全部的評審最多兩次。**經過這種方式，倒逼利益相關方儘量地作好需求與方案設計。評審會議組織前，嘗試與全部相關人員達成一致，詢問對方的意見，並進行有針對性的討論，這樣可以大大提高評審會議的效率和質量。若是在第一次評審中不經過，那麼就只有一次機會進行復審。一旦兩次不經過，就須要進行Casestudy。

「事不過二」原則的另外一層含義，是「一樣的錯誤不能犯第二次」。每次故障以後，Casestudy都必須進行深入的總結覆盤，對故障緣由進行5Why分析，給出明確可執行的To Do List。每次季度總結會，你們自我檢討問題所在，在下個季度必須有所改善，不能再犯相似的錯誤。孔子云：「不遷怒，不貳過」，在錯誤中反思與成長，才能讓咱們成爲更優秀的人。

原則七：設計優先

「設計優先」這條原則，相對來講更加具體一些。之因此單列一項，是由於架構設計過重要了。Uncle Bob曾說過：「軟件架構的目標，是爲了讓構建與維護系統的所需人力資源最小化。」

架構設計，並不只僅關係到系統的質量，還關乎團隊的效能問題。不少團隊也有明文規定，開發週期在3pd以上的項目必須有設計文檔，開發週期在5pd以上的項目必須有設計評審。在具體的執行過程當中，因爲各類緣由，設計每每並不能達到預期的效果。究其緣由，有的是由於項目週期緊，來不及設計得足夠詳細；有的是由於RD主觀上認爲項目比較簡單，設計草草了事。無數事實證實，忽略了前期設計，每每會致使後續開發週期被大幅拉長，給項目帶來了很大的Delay風險。並且最可怕的是，不當的設計會給項目帶來巨大的後期維護成本，咱們不得不騰出時間，專門進行項目的優化與重構。所以，不管何時都要記住「設計優先」這一原則。磨刀不誤砍柴工，前期良好的設計，會給項目開發以及後期維護帶來極大的收益。

「設計優先」這一原則，要求寫別人看得懂的設計。咱們瞭解一個系統最直接的途徑就是結合設計文檔與代碼。在實際工做中，不少同窗的設計文檔讓你們看得一頭霧水，通篇下來，看不出系統總體的設計思路。其實，設計的過程是一種智力上的創造，咱們更但願它能成爲我的與集體智慧的結晶。如何才能讓咱們的設計變得通俗易懂？我我的認爲，設計應該儘可能使用比較合理的邏輯，進而把設計中的一些點組織起來。好比可使用從抽象到具體，由總到分的結構來組織材料。在設計過程當中，要以需求爲出發點，經過合理的抽象把問題簡化，講清楚各個模塊之間的關係，再詳細分述模塊的實現細節。作完設計以後，能夠發給比較資深的RD或者PM審閱一下，根據他們的反饋再進行完善。好的設計，必定是邏輯清晰易懂、細節落地可執行的。

原則八：P/PC平衡

「P/PC平衡」原則，即產出與產能平衡原則。伊索寓言中講述了一個《生金蛋的鵝》的故事。產出比如「金蛋」，產能比如「會下金蛋的鵝」。「重蛋輕鵝」的人，最終可能連產蛋的資產都保不住；「重鵝輕蛋」的人，最終可能會被餓死。產出與產能必須平衡，才能達到真正的高效能。爲了讓你們更清晰的瞭解這一原則，本文舉兩個例子。

從系統的角度看，每個系統都是經過持續不斷地疊加功能來實現其產出，而系統的產能是經過系統架構的可擴展性、穩定性等一系列特性來表徵。爲了達到產出與產能的平衡，須要在不斷支持業務需求的過程當中，持續進行技術架構層面的優化。若是一味地作業務需求，通過必定的時間，系統會愈來愈慢，最終影響業務的穩定性；反之，一個沒有任何業務產出的系統，最終會消亡。

再從RD的角度來看這個問題，RD經過作需求來給公司創造價值，實現本身的產出。而RD的產能是指技術能力、軟素質、身體健康情況，有這些資本後，咱們才能進行持續的產出。在平常工做中，我發現不少RD每每只重視產出。他們也在很努力地作項目，可是每個項目所使用的方法，仍是沿用本身先前一向的思路。最終，不只項目作得通常，還會抱怨本身得不到任何成長。這就是P/PC不平衡的體現。若是能在作項目的過程當中，經過學習總結持續提高本身的技術能力和軟素質，並將其應用於項目實施交付中，相信必定會取得共贏的結果。

「P/PC平衡」原則還適用於不少其餘的領域，例如團隊、家庭等，我本人也很是推崇這一原則。但願你們也能將其做爲自身的一項基本原則，努力尋找到產出與產能的平衡點。

原則九：善於提問

「善於提問」，首先要勤於提問。求知慾源於好奇心，是人類的一種本能。在工做中要養成勤於提問的好習慣，不懂就問，不要由於本身一時懶惰或者礙於情面，就放棄提問的機會。當遇到不一樣的觀點時，也要禮貌地問出來。波克定理告訴咱們，只有在爭辯中，纔可能誕生最好的主意和最好的決定。

在設計評審、代碼評審這類體現集體智慧的活動中，遇到有問題的地方必定要提出來。我常常看到，不少同窗評審全程一聲不響，這就是浪費你們的時間。設計評審的目的，是讓你們針對方案提出改進意見並達成一致，若是全程「打醬油」，那就失去了評審的意義。咱們鼓勵你們多提問，把本身心裏的疑惑表達出來，而後經過交流的方式獲得答案。

「善於提問」，還要懂得如何提問。爲何一樣是參加設計評審，有的同窗就能提出很好的問題，而有的同窗卻提不出任何問題？除了知識儲備、專業技能、經驗等方面的差別外，還有一點很重要：批判性思惟。

批判性思惟主張經過批判性思考達到理性思惟，即對事物本質的認知和掌握。關於如何進行批判性思惟，你們能夠參考一些經典的圖書如《批判性思惟》、《學會提問》等。在工做中面臨一項決策時，會有各類各樣的意見擺在你面前，因此咱們必需要學會使用批判性思惟來進行分析，每一個人的論據是否可靠，論證是否合理，是否有隱含的立場。一樣，在閱讀一篇技術博客的時候，也要使用批判性的思惟，多問幾個爲何，做者得出的結論是否合理？論據是否充分？只有這樣，才能不斷地獲取真正的知識。

原則十：空杯心態

「滿招損，謙受益」，「空杯心態」是最後一項原則。我以爲這也是一我的可以持續成長的前提。作技術的人，骨子裏一般有股傲氣，而且會隨着資歷、成績的提高而不斷增長。初入職場的小白，可能會很是謙虛，可是工做幾年以後，專業技能逐步提高，可能還取得了一些小成就，人就會愈來愈自信。這時候，若是不能始終保持「空杯心態」，這種自信就會逐步演變爲自滿。自滿的人，每每表現爲工做中把別人的建議當成是批評，不接受任何反對意見，學習上也缺少求知的動力，老是拿本身的長處去跟別人的短處作比較。其實每一個人多少都會有一些自滿，可怕的是不知道甚至不肯認可自滿。

保持「空杯心態」這一原則要求咱們時刻進行自我檢視與檢討。在工做中，多去跟不一樣級別的同窗聊一聊，或者作一個360度評估，這有助於咱們更加客觀地評價本身。在橫向對比中，多向那些優秀的同窗看齊，學習他人的優勢。不少同窗在設計評審或者代碼review過程當中，針對別人提出的問題與建議，每每都採用一種對立的態度。錯誤地認爲別人是在挑刺，是在針對本身。誠然，在某些方面，咱們可能確實比其餘人想得深刻，可是這不表明在全部方面都能考慮周全。對於別人的建議，建議使用「善於提問」原則裏提到的批判性思惟仔細分析一下，虛心地吸收那些好的建議。

工做學習就像「練級打怪」，技能儲備的越多，就越容易走到最後。保持空杯心態，可讓咱們發現不少之前注意不到的新能力，咱們要作的就是努力學習它，將它們轉化爲本身能力庫的一部分。

總結

以上，是我總結的工做與學習的十條基本原則。其中有的側重於我的作事情的方法，如「Owner意識」、「時間觀念」、「以終爲始」、」閉環思惟」；有的側重於團隊工做標準規範，如「保持敬畏」、「事不過二」、「設計優先」；有的側重於團隊或我的效能提高，如「P/PC平衡」、「善於提問」、「空杯心態」。這些原則是我多年在工做與學習中，不斷總結得來的經驗。但願在你們面臨選擇時，這些原則可以起到必定的幫助和指導做用。

以原則爲中心地工做與生活，讓本身與團隊變得更增強大。

做者介紹

雲鵬，2014年加入美團，前後參與了美團酒店供應鏈體系、分佈式調度系統的建設，如今負責美團旅行客戶關係管理系統、基礎信息服務的建設工做。