不四：產品工程師的修煉之路

簡介： 我是不四，畢業後一直在阿里和螞蟻工做，不四是我在阿里的花名，社區中通常以另外一個花名 「死馬」 出現。每個人的成長軌跡都不同，一路上遇到的機遇也各不相同，此次分享也僅站在一個普通工程師的角度來分享個人成長經歷和貫穿其中的一些我的習慣。

做者 | 死馬

我是不四，畢業後一直在阿里和螞蟻工做，不四是我在阿里的花名，社區中通常以另外一個花名 「死馬」 出現。工做這 8 年多來一直專一在 Node.js 和 Web 開發領域，也在社區參與了一些開源項目，包括 Koa、Egg 和 cnpm 等，很是幸運在 node 出生之初就開始參與其中，算是遇上了一波由 node 帶來的大前端變革浪潮。每個人的成長軌跡都不同，一路上遇到的機遇也各不相同，此次分享也僅站在一個普通工程師的角度來分享個人成長經歷和貫穿其中的一些我的習慣。

成長曆程

實習

在 2011 年的夏天，大三暑假我來到了當時的淘寶數據平臺實習。也不知道是運氣好仍是運氣差，我是以 C++ 工程師的身份被招聘的，分配到的數據產品部倒是一個作 Web 產品的團隊，仍是用剛剛出生的 Node.js 做爲服務端開發語言，並在實踐全棧研發，還記得那時候 node 的版本才 0.4，而我是一個連 JS 和 JSP 都分不清楚的菜鳥，大學三年只寫過黑框框的 C++，連 HTTP 是什麼都不知道，無比忐忑的開始悶頭學習 JS 基礎。

多年之後和當時看的入門教材做者成爲了同事。

幸運的是，當時的團隊大牛雲集，國內第一批 Node.js 的佈道者，node party 的發起人空無、清篤、玄澄，以及國內 node 社區一直以來的核心貢獻者蘇千和樸靈等等都集中在了這個團隊。跟隨着他們的腳步，我在大半年的實習時間內，順利的將 C++ 給忘光了，成爲了一名新手 JS 工程師。

數據產品部

12 年畢業後正式入職淘寶數據產品部，那是大數據最火熱的年代，咱們坐在淘寶數據平臺的金山上，挖掘出來了數據魔方、淘寶指數、淘寶時光機等數據產品。隨着我慢慢的深刻業務，也逐漸理解了團隊爲何選擇 node 技術棧。大部分的數據產品自己的計算和業務邏輯相對不會太複雜，依賴大量後端數據源提供數據，是一個典型的 IO 密集型應用。而 JS 全棧也能夠帶來更高效的研發效率。

數據魔方

淘寶時光機

隨着數據產品覆蓋的場景愈來愈多，咱們須要對接到阿里集團的各類內部系統。因此咱們用 node 實現了內部的微服務框架、登陸系統、配置系統等中間件。而隨着 node 生態的愈來愈繁榮，搭建一個內部的 npm 包管理系統也提上了日程。咱們嘗試着用 npm 官方的解決方案搭建，可是難以運維，也不能徹底知足需求，最後咱們開發了 cnpm 用來搭建內部的 npm 包管理平臺並提供了國內的 npm 鏡像。後來的事實證實，一個快速的 npm 包管理平臺對於促進 node 和大前端社區的繁榮起到了相當重要的做用。

剛畢業的這兩年是我技術成長很是快的時候，一方面是團隊有不少大牛能夠學習，另外一方面也遇上了一波 node 技術初生的福利期，我也在這裏完成了工做後的第一次晉升，從 P4 晉升到 P5。

天貓前端

在 14 年中的時候，因爲團隊的一些變化，我轉崗到了天貓前端團隊。當時的天貓前端團隊其實沒有專職的 node 開發工程師，團隊遇到的一個很大挑戰是運營活動頁面以前都是運行在 php 上，隨着 php 工程師在阿里的逐漸減小，那套年久失修的 php 系統已經難以繼續支撐流量愈來愈誇張的雙十一活動了。因此我開始着手經過 node 實現新一代的頁面渲染服務。

新服務在 14 年雙十一的時候在天貓首頁進行驗證，從性能和穩定性上比老的 php 服務高出不少。接下來咱們開始基於新的服務上層實現了新的可視化頁面搭建系統，很是完美的支持了 15 年的雙十一，這套系統也一直服務到如今，固然已經進化的更加完備和複雜了。

當時給 php 和 Node.js 系統作的 benchmark

在天貓能夠說是以前那段工做經歷積累後的爆發期，用一個全新的技術棧實現了一個重要的業務系統，並取得了很大的業務價值，因此在 15 年的時候我也從 P5 晉升到了 P7。

螞蟻體驗技術部

可能仍是有想作更底層一點技術的念頭，我在 16 年初的時候決定從天貓前端團隊轉崗到螞蟻的體驗技術部給大前端團隊作內部的 Web 框架和 BFF 研發模式的支持。其實在去螞蟻以前，我也一直在維護者 Koa 和一些 Web 框架生態和中間件的服務，到螞蟻以後參與作的第一件事情就是從當時螞蟻的 Web 框架 Chair 中抽出來了 Egg.js，以統一阿里經濟體各不一樣 BU 的大前端 Web 研發體系。Egg.js 也隨後面向社區開源。

Egg.js 生態

經過兩年多時間的發展，BFF 研發模式也慢慢的被螞蟻、阿里經濟體甚至是國內接受了。我也在這裏晉升到了 P8。

語雀

隨着一次內部組織架構調整的機會，我來到了語雀團隊。它是螞蟻體驗技術部內部的一個創新孵化項目，爲十萬阿里人提供知識協同和文檔管理的服務，18 年的時候，語雀也開始對外服務。兜兜轉轉的走了一圈，我又回到了使用 JS 全棧進行應用開發。在語雀團隊，咱們踐行着產品工程師文化，高效的完成產品研發。

語雀產品工程師文化

簡短的總結畢業後的這 8 年，我在一個公司內兜兜轉轉，可是一直專一在一個技術領域上，並在底層技術、基礎服務、產品研發等不一樣的方向作探索。成長過程當中可能有不少的幸運，你能遇到什麼樣的團隊和老闆，能夠作什麼樣的事情，這些可能咱們都很難徹底控制，可是咱們可以控制的是做爲一個工程師，你如何提高本身的技術能力，作好抓住機會的準備。

工程師成長密碼

回過頭再來看這幾年，我在工做和社區中養成了一些習慣，這些習慣多是對個人技術成長影響很是大的。

堅持寫代碼

顯而易見，做爲一個工程師，咱們最重要的職責就是寫代碼。熟能生巧，堅持寫代碼必定是工程師成長手冊中最重要的一點。不管是在作技術項目仍是帶團隊，寫代碼必定是我平常工做中最重要的一部分。

然而低質量的重複是毫無心義的，咱們要堅持寫代碼，更要堅持寫好代碼。

什麼是好的代碼？這個問題可能不一樣的人眼中有不一樣的答案，對我而言，好的代碼起碼要知足這三個條件：

1. 好的代碼是簡單的，簡單的代碼架構清晰，而且讓編碼變的更輕鬆；
2. 好的代碼是給人看的，絕大部分的應用都是要持續維護的，不給別人挖坑，也是不給將來的本身挖坑；
3. 好的代碼是可測試的，經過編寫單元測試，既保障代碼的邏輯完備，減小 Bug，也利於後期維護與重構。

保持代碼簡潔

先從簡單提及，簡單的代碼是容易理解的，然而想要編寫簡單的代碼，架構起來又是更復雜的。這是給本身提出更高的要求，不斷優化重構，在這個過程當中獲得成長。當遇到一些複雜需求的時候，我始終堅信一點：若是一個邏輯咱們做爲實現者都很難梳理清楚，代碼中一堆的 if else 條件判斷，那用戶也必定是沒法理解的。

因此當遇到這種狀況，咱們須要從產品側和架構側去思考，究竟是什麼緣由致使了複雜度？咱們應該是去優化產品需求仍是去優化底層架構。這也會迫使咱們在產品和架構上有更深刻的思考。

Code Review

另一個我和團隊一直在堅持的習慣是 Code Review。CR 是一個很是好的提高代碼質量的方式，它是須要團隊投入大量精力的事情，可是必定收穫不菲。

咱們直面 CR 的靈魂三問：

1. 爲何要作 CR？業務催的那麼緊，哪有時間作 CR？
2. 誰來作 CR？是團隊的主管、核心工程師才能幫別人 CR 嗎？
3. CR 是一件很費精力的事情，如何才能堅持下來呢？

Code Review 的主體是人， Review 的對象是代碼

• 對於代碼提交者的人來講，當你知道你的代碼會被其餘人看到的時候，是確定會更加註重代碼質量的。我還記得我開始向社區成熟開源項目提交代碼的時候感覺到的巨大壓力，它會讓你在提交代碼前更仔細的設計和編碼。通過一次次的 CR 後，你會發現你的代碼質量會飛速提高。
• 對於評審人來講，每一次 CR 均可以增長你對總體代碼庫或者不一樣業務的熟悉程度，還能夠傳授經驗、提高團隊影響力。
• 最後，經過 Code Review，咱們能夠提高項目代碼的質量與可維護性，統一團隊的代碼風格，並讓每個業務邏輯都能儘可能找到 back up。CR 是一件三贏的事情。

CR 是一件頗有意義的事情，可是咱們應該怎麼去作呢？

第一步仍是要從本身作起，經過本身的主動與堅持，帶動團隊一塊兒參與。在提交代碼的時候，寫好 commit message，作好自測，注意代碼的可讀性。抽時間來 Review 團隊其餘人的代碼，爲每一行代碼負責。

可是 CR 畢竟仍是一個團隊的事情，如何保持團隊 CR 的質量呢？咱們必定要嚴抓新人的第一次 CR。通常來講咱們團隊新人的第一個 PR 都會收到比較大的挑戰。新人對代碼不熟悉，編碼風格也和團隊可能不一致，第一次 CR 很是重要，須要讓你們都對齊對代碼質量的標準和要求。

對新人重拳出擊

除了代碼以外，更上層的設計與架構也須要作 Review，讓每一次系統功能設計、架構升級都通過 Review，不只可讓系統更穩定，也能夠快速提高本身的系統架構能力。

Unit Tests

• 你的代碼質量如何度量？
• 你是如何保證代碼質量？
• 你敢隨時重構代碼嗎？
• 你是如何確保重構的代碼依然保持正確性？
• 你是否有足夠信心在沒有測試的狀況下隨時發佈你的代碼？

若是對這些問題沒有答案，或者沒有 100% 的信心，那你須要給你的代碼作單元測試。

如今提及單元測試，你們其實仍是有體感的。然而在 十二、13 年我剛工做的時候，單元測試仍是一個相對陌生的概念，可是當時的 node 開源社區其實已經慢慢開始流行起來寫單元測試了，當你給其餘開源項目提交代碼的時候，沒有測試是不可能被合併的。當時高產的 TJ 不只僅提供了 express connect 等 Web 框架，同時也提供了一系列底層配套的測試模塊，包括測試用例驅動器 Mocha，斷言庫 should.js，http 請求測試庫 supertest 等等。

跟隨社區一塊兒，咱們很早就把單元測試引入了咱們的工做中，基本上從我正式工做開始編寫的第一行項目代碼開始就在寫單元測試了，這個習慣讓我在 8 年的工做經歷中保持了不錯的代碼質量，在沒有測試工程師測試過個人代碼的狀況下，沒有搞出重大故障被阿里開除。

提及對業務代碼寫單元測試，可能你們的第一反應仍是哪有時間寫單元測試啊？其實寫單測真的沒有那麼耗時，只要你找對工具和方法。對於單元測試來講，只須要四個步驟：

1. 建立一些初始數據；
2. 對外部依賴進行 mock；
3. 最小粒度的執行要測試的方法；
4. 對結果作斷言。

剩下的就是按照這個方式構造測試用例輸入，儘量的覆蓋代碼中的每個分支和邊緣場景。

Web 應用中的單元測試更加劇要，在 Web 產品快速迭代的時期，每一個測試用例都給應用的穩定性提供了一層保障。API 升級，測試用例能夠很好地檢查代碼是否向下兼容。對於各類可能的輸入，一旦測試覆蓋，都能明確它的輸出。代碼改動後，能夠經過測試結果判斷代碼的改動是否影響已肯定的結果。咱們在作 Egg.js 的時候，最重要的一件事情就是給它編寫對應的測試框架，讓業務方可以更簡單、沒負擔的寫單測來保障代碼質量。

而把代碼的覆蓋率提升，看到測試覆蓋率的報告全綠，不只對上線代碼更有信心了，同時也是一件頗有成就感的事情。

持續分享

若是說堅持寫代碼是練習和輸入，那另外一個對我成長幫助很大的習慣就是分享，這看起來是一個對外的輸出，但在我看來它更是一個很是好的學習機會。

在我剛工做在數據產品部的時候，咱們團隊組織了一個 Show Me The Code 的內部分享沙龍，是一個形式很是隨意的分享會，不須要準備正式的 PPT，不須要很長的分享時長，就簡單的分享一下最近學到的新知識，看到的有趣的代碼。這個培養了我去分享的習慣。那時候常常爲了找一個分享的話題，去主動研究一些新的模塊，看他的源碼，本身也會去造一些小的輪子來解決實際工做中遇到的重複性工做。而如今在語雀團隊，我也在組織內部雙週分享會，已經堅持了一年多的時間了。

再小的分享也會有收穫

工做的這些年我也陸陸續續在外面的會議進行了很多的外部分享。基本上每一次分享，都須要本身先認真的對要分享的內容查漏補缺，並嘗試着將它準備到淺顯易懂。每一次演講事後，都會讓你對這個演講主題的領域有更深的感覺。

分享對我來講更多的是給我提供了一個很是好的階段性總結的機會，最好的學習方法就是教會別人，由於誰也不想在臺上出糗對吧。去聽一場技術分享，聽到的知識轉眼就忘了，而你認真的去準備一場演講，那場演講收穫最大的必定是你本身。

參與開源

對個人技術成長影響很大的另外一個因素是開源，固然開源本質上也是一種分享。

如今是一個百花齊放的年代，開源世界的項目愈來愈多，根據 GitHub 的數據，2019 年有 4400 萬個新項目被建立。每個有技術追求的工程師可能都想過要去 GitHub 上寫點什麼。可是開源並非指的在 GitHub 上提交代碼，開源更多的是一種心態。

1. 開源意味着你要將你的代碼給全部的開發者審閱，就像前面 Code Review 的時候說的，把代碼給別人看是一件頗有壓力的事情，更況且提交到 GitHub 後，全部人都能看到，你的同事、面試官都能看到。必定要認真的對待每一行代碼，每一次提交。
2. 同時當有人使用你的開源項目時，意味着你要承擔起責任。儘管開源協議多是很寬鬆的 MIT，但仍是要對你寫的代碼負責。
3. 開源應該讓你感覺到 「痛苦」，須要對開源代碼提出更嚴格的要求，追求最優的代碼架構，測試完備，描述清晰，編寫高質量代碼的過程會讓你感覺到痛苦，可是會有更快的成長。

可能咱們有時候很難本身想到一個很好的想法，或者很難本身實現一個那麼高質量的開源項目，不要着急，參與開源的門檻其實也沒那麼高。

第一步，挑選一個工做中能夠用到的領域的高質量開源項目，爲何工做中能夠用到很重要，由於這樣你才能更好的找到改進的方向，找到痛點。例如我當時選擇深刻參與的開源項目是 Koa，由於我工做的重點也是在 Web 研發領域，而我以爲 Koa 當時基於 co 提供的那套異步編程模型必定是將來的趨勢。

第二步，逐步參與進去，一開始可能只是修一下文檔，找找 Bug 修復一下，補充幾個測試用例。慢慢的隨着你對代碼和周邊生態的完善，能夠進一步去實現一些缺失的周邊生態，嘗試根據本身實際遇到的問題給項目提交一些功能改善。

國外有不少高質量的項目，咱們也能夠幫他們作文檔的翻譯。不要小瞧文檔翻譯，翻譯一遍文檔就意味着你要深刻理解這個項目，其實也是一件很難而且頗有收穫的事情，還可以提高社區影響力。

開源是一個成就感驅動的事情，由於你沒法從中得到看得着的收益。因此可以持續的參與開源最重要的一點是你要可以從中找到成就感。

和團隊一塊兒成長

說了這麼多我的成長的事情，我仍是想再稍微說一下團隊。咱們做爲我的在團隊中工做，只有幫助團隊一塊兒成長，拿到業務價值，才能將咱們的技術成長 「變現」。而以前提到的 Code Review 亦或是單元測試，都是須要團隊一塊兒來配合的。

若是你的團隊尚未內部的分享會，嘗試着本身去組織一個按期的內部分享會；
從如今開始作 CR 和單測，用本身來影響團隊；
嘗試着在團隊中創建契合團隊的工程師文化。
前兩點其實在以前的分享中都已經說起到了，這也是咱們團隊一直在堅持和倡導的。我想說一下語雀的團隊文化，在語雀咱們但願每個工程師都是產品工程師，他是產品的技術合夥人，參與產品討論、完成產品功能研發，同時他也是某一個具體領域的技術專家，例如前端 UI 組件、編輯器領域、服務端領域等等。在咱們的工做流程中，全部的工程師都是以全棧的身份參與項目研發，跟進項目從產品設計、到系統分析、研發自測，CR 以及上線的全流程。經過產品工程師文化，咱們鼓勵每個工程師都可以在業務和技術上找到本身的成長方向，並陪着團隊和業務一塊兒快速成長。

我的成長很重要，同時想要取得好的結果獲得晉升，必定要將我的的成長和團隊的成長綁定起來。經過把本身的事情作到極致，幫助團隊創造業務價值，在這個過程當中提高本身在團隊內外的影響力。找到那個我的和團隊共贏的點去發力，能夠獲得事半功倍的效果。

本文來自 螞蟻集團高級前端技術專家 不四在前端早早聊成長晉升專場的分享。