神三元在抖音架構組的八個月，他經歷了什麼？

從去年入職字節到如今，已經有 8 個多月的時間了，今天來跟你們分享一下個人一些感覺和想法吧。

之因此在這個時間點發出來，是由於我剛剛結束了本身的實習生涯，等今年畢業後再來的時候，就再也不是實習生了。我以爲人生須要一些儀式感，我也須要一些時間來整理本身的想法，從繁忙、快節奏的工做當中脫身，去反思本身作的很差的地方，對過去這麼長時間的經歷作個總結，畢竟這樣的機會真的很少。

我經歷了什麼？

初來乍到

剛來的時候，據說是抖音的架構團隊，感受很厲害。第一天見了 leader 以後，他告訴了我兩件事，第一，每一個程序員都有一個作架構的夢想，我還沒畢業就加入了這樣的架構組，得好好珍惜這裏的機會；第二，這裏作的事情基本上都是各類各樣的挑戰，會遇到不少困難，作好心理準備。

當時聽完既欣喜又有點畏懼，能進入這樣一個團隊是多麼酷的一件事情，但同時也擔憂本身水平和能力不夠，接不了這個挑戰。

懷着這樣的心情，我加入到了第一個項目組，當時作公司的低代碼平臺，即經過拖拽生成網頁的平臺，固然在這塊如今業內也有很多的實踐了，技術複雜度不用說，確定是至關高的。

當時有幾個和我一塊兒來實習的夥伴，入職了一週之後聊起來，他們說進了業務團隊來了不到兩天就開始接需求、提交代碼了，但我仍是空空如也，啥也沒作，心理上不免有些落差。

中途我也找 leader 聊過本身的想法和困惑，他表示在這個團隊當中前期上手的門檻會相較比較高，須要有一些耐心，同時也給了我不少開導，在感激的同時，我也深表贊同，打算沉下心來，繼續熟悉項目。

但過了不久，我開始接觸到團隊當中其餘的一些項目，看到團隊當中也在作工程化腳手架相關的事情，正好以前在社區裏接觸過，比較感興趣。想到本身仍是處於實習階段，爲什麼不選擇一個本身更感興趣的方向去試一試呢？所以，我跟 leader 和當時的 mentor 表達了本身的想法，他們也很爽快的贊成了。

還記得當時這個低代碼平臺只去了半個月了，後面轉到了工程化方向，一待就是 8 個月的時間。剛開始轉到這個方向，覺得僅僅只是個腳手架，但 mentor 立刻糾正了我，他告訴我這是一個龐大的工程體系，覆蓋初始化、開發、調試、CI、CD 等完整的開發流程，全面提高工程質量和工程效率。我當時一聽，不明覺厲，甚至還有點小激動。（你們如對工程化的機會感興趣的來找我私聊吧，這個組是真的很須要人，wx: sanyuan0704）

就這樣，我開始了在工程化小組這邊全新的征程。

渴望挑戰

接下來一段時間的工做就比較順利了，逐步上手了相關工具的開發，閱讀了一些子模塊的實現，而且寫了近萬字的源碼解析被轉到了部門羣，也算是對新人培養體系的貢獻。

mentor 常常安排一些小的功能讓我去作，出了一些使用上的小 bug 也會讓我去 fix 一下，文檔方面須要完善的也會叫我去補(ban)充(yun)。接下來接近兩個月的時間，基本是作這些。

這樣零碎的事情作久了我也不太喜歡，雖然中間有一些挑戰，但總體上並無一個獨自 own 的模塊。中途找 leader 談了談本身的想法，也跟 mentor 交流了下後續的計劃，我也理解他們實際上是擔憂給我太難的工做我接不住，直接翻車了後果很嚴重。但面對即將到來的轉正答辯，若是手頭一個獨自負責的模塊都沒有，都是些零碎的事情，未免有點捉襟見肘了，因此跟 mentor 說不妨給我安排一些能夠獨立負責的模塊。

果真，提出個人想法以後，mentor 開始給我分一些比較大的模塊了，我後面選擇了其中一個做爲答辯項目，是一個線上調試相關的工具，大概作了兩個月，最後也順利經過了答辯，拿到了還不錯的 offer 評級。固然，在秋招當中，也直接接了字節的轉正 offer。

專一深耕

答辯完回了一趟學校，那個時候仍是 2020 年的 9 月份，再次回到字節的時候已是 2021 年 1 月初了，大概請假了 4 個月的時間。能夠說這是我第二段實習的經歷了，相較於上一段經歷而言，這一次實習的難度和壓力都上升了好幾回檔次，遇到了至關多的挑戰。

剛來的時候，mentor 給我私信，叫我去熟悉一下目前工程體系當中 SSR（服務端渲染）相關的內容，以前堆了不少需求，還有一些體驗問題，沒有人力跟進，如今要我把這部分承擔起來。

說實話，面對 4000 多行的運行時框架，我不知道從何入手，連續看了兩天源碼沒咋看明白，沒想到第三天就接到 SSR 的新需求了，不由讓我感覺到一種巨大的挑戰。

剛來的第一週硬着頭皮啃下來了大部分的細節，而且在周圍大佬的指導下弄清楚了一些邊界 case 的實現。

在作完以前堆積的一些 SSR 需求以後，mentor 跟我說目前的 SSR 是工程體系當中很重要的一個板塊，須要好好思考一下，作一個長期的規劃。因而，在那段時間當中，我逼着本身去調研了業內的許多 SSR 方案，包括Nextjs、egg-react-ssr、ssr，包括公司內部的一些方案，也對SSG、SPR、ESR作了一些研究。這個過程，既是在梳理將來的規劃，也是在提高本身的視野，逐步進入技術的深水區。

以後我也一我的負責了 SSR 框架的 oncall(給使用這個框架的業務方答疑、解決 bug) 和新需求的迭代，按照預期的規劃一步步推動，在建設 SSR 框架的同時，也對 SSR 技術自己有了更深刻的理解。

咬牙堅持

原本想着能夠全身心投入到 SSR 當中，但實際上卻並不是如此，因爲咱們的工程化框架須要落地到業務當中，因而 mentor 把我分配到了幾條重要的業務線當中，做爲 BP(即 Business Partner) 的角色去支持業務，沒想到這些工做佔據了我後期全部的人力，能夠說中間困難重重。

首先是據說公司裏面一個很重要的海外視頻網站項目須要改造，日活是我作夢都想不到的級別，mentor 讓我來負責改造的工做，改完了以後給業務方提個 MR(Merge Request)，讓他們合一下就能夠。

但改造的過程比我想象中更加艱難，一方面咱們組作的構建工具當中纔剛剛封裝完 Webpack5 的部分，並無對外發穩定的版本，不免會踩坑或者遇到不支持的地方，這是內部的因素。另外一方面，業務方對項目質量的把控很是嚴格，好不容易跑起來沒有報錯了，他們反饋說改造以後打包體積多了 20 幾 KB (當時的完整打包體積是 500 多 KB)，光優化這 20 幾 KB 的體積，又得付諸好幾天的時間和精力，最後才勉強達到他們的預期。

除了構建部分，後續又涉及到其餘模塊的改動，這裏就不過多透露細節了。總而言之，是一個很是複雜的改造過程，中間有一段時間扎進項目當中，遇到了一些 block 的地方，也好幾天睡不着覺。但改造結果還算成功，最後知足了業務方全部的需求，讓那個日活上億的海外產品跑起了我寫的代碼hhh（逃

接下來的一段經歷是去作抖音的五一活動 BP，這也是我第一次參與到一線的業務開發當中，總體開發時間緊、強度高，你們一塊兒坐在同一個封閉會議室，如同戰友通常，Bug 一改就是一成天。在上線前的一個周，爲了 Bug 日清，基本是天天凌晨之後才能下班。

雖然過程會比較辛苦，但真實地參與了一線業務開發的完整的過程，包括從需求評審、功能開發、與客戶端/Server 端聯調、QA 提測、反覆衆測、部署上線，更重要的是，看着本身的代碼上線，被無數的人使用到，真的是一件很有幸福感的事情！

工做後的感覺

時間管理的挑戰

儘管是實習生，但也是大小周，天天出勤的時間也跟正式工沒有什麼區別。工做之後給我最大的感覺就是本身的時間被切得很是碎了，常常容易被各類事情打斷，而且工做會佔據本身絕大部分的時間，可以本身自由支配的時間能夠說很是有限，像在學校裏面什麼都無論、悶頭學東西的狀態已經一去不復返了。

這就意味要想在這種環境下面保持學習的狀態，就學會和碎片化的時間相處，學會合理規劃和安排本身的時間。但其實我自己並不擅長時間管理，以前上學的時候能一我的能埋頭鑽研個好幾天，如今沒有了這種環境，因此有時候也會感到束手無策。

我跟你們同樣，也有技術焦慮，每當看到一些新潮的工具框架、或者讓我眼前一亮的技術，我都會想要去了解一下，但時常也由於時間和精力不夠，學習的不夠透徹，甚至過了一段時間就忘得差很少了。可能咱們真應該想想，是否是本身時間管理上出了問題？

其實我以爲時間管理本質上仍是在於對精力的管理，若是很差好思考一下如何投入和規劃本身的精力，天天被動地陷入一種常態的、快節奏的工做模式，那麼天天會浪費大量的時間而不自知，這是一件很惋惜的事情。

架構組須要什麼樣的人？

待在架構組，與待在業務團隊當中，對於工做能力的要求是很是不同的。可能你會說了，這還用說，在架構團隊固然對技術能力的要求更高啊。但從一個架構團隊的內部視角出發，我想說的是，你們都忽略了一個很重要的事情，就是咱們完徹底全是靠本身在打磨一個個技術產品，注意，是產品。既然是作一個產品，那麼就必須得經歷需求分析、用戶界面設計、產品功能設計、代碼開發、進行各類測試，那麼就得經過必定的運營手段讓產品被用戶看到，最後達到用戶的面前，交付給用戶。

可是，這一切的一切，全由架構團隊的開發人員本身來完成，也就是說，咱們沒有本身的 UI、沒有本身的 PM、沒有本身的 QA，一我的或者一個開發團隊，就扮演了全部的角色。若是最後的技術產品出現了問題，確定是中間某一個環節沒有作到位，這個環節並不是僅僅是技術自己的問題。

挺認同一個觀點: 做爲一個程序員，爲了發展得更長遠一些，最好須要懂一點 UI，懂一點產品，懂一點運營。坦白地講，這些放在業務團隊裏面，實際上是一個可選項，不少時候不懂也沒有太大問題，有更專業的人給你 backup，萬一 UI、體驗作的很差，會有更專業的人給你指出來，也不須要操心什麼運營推廣的事情。但放到架構團隊，幾乎都是必備項，你得會站在業務的角度挖掘和分析需求，你得會設計符合用戶使用習慣的工具和文檔，你得會設計完備的測試用例保證技術產品的質量，你也得會向外人宣傳、推廣和落地本身的技術產品，這些都得你一我的作。

在架構組，帶給我更多的是一種力不從心的感受。由於咱們作技術產品，對於咱們開發人員自己的要求更加的全面和多元化，一個環節出了問題都是巨大的隱患，並且更重要的是，這些問題咱們通常是後知後覺的。除非是使用的業務方拋出問題給咱們，咱們不會發現本身的文檔還有這麼多不清晰的地方，咱們不會發現本身的測試用例都沒寫竟然就把代碼發佈了(我先面壁思過)。

咱們是能經過外界獲得反饋，無論是 oncall 提問仍是直接吐槽的方式，但這樣致使的問題是，其一，若是做爲架構團隊的一員，真的是連最基本的產品意識和能力都缺少，致使作出的工具漏洞百出，從而須要處理海量的 oncall 問題，這個維護成本是否是也在反過來抑制整個團隊的產出，造成惡性循環？其二，若是用戶以爲能用，但用的不舒服，不想反饋，是否是這樣的問題就一直殘留在咱們的技術產品當中，而被咱們給忽略掉了呢？看不見的問題，每每也是最致命的。

綜上所述，是我以爲待在架構組感到力不從心的緣由，固然也是我後續須要努力的方向，同時也是本身對這份工做崗位的一些理解。與其說團隊須要的是技術大拿，不如說是須要把技術產品作好的人。

痛，併成長着

這一點就比較帶有我的色彩了。坦白講，一開始我是進去準備深耕 SSR 這塊內容的，但後來被分配到業務當中，沒想到會佔用我那麼多的精力，何況大部分時間都花在了業務項目自己。其實這是我不太願意接受的，中途也所以心情很是糟糕，甚至和業務方大佬直接在羣裏開撕。但沒辦法，這個事情必須得作，並且也應該交給我作，由於換了人還得花不少時間熟悉業務，只會拖得更久。

工做之後，感受不少時候咱們是身不禁己的，不少事情，即便不情願，仍是須要本身扛下來。這個事實咱們沒法改變，但咱們能夠改變的是看待它的視角。

參加業務、熟悉業務的過程雖然給了我很大的心理負擔，但這個過程當中我看到了一個大型項目如何搭建腳手架、設計測試用例、搭建 e2e 測試環境、進行服務器性能壓測等等實踐經驗，也參與到業務當中，如何作好埋點監控、降級容災等等工程環節。這又未嘗不是一種成長呢？過程看起來很辛苦，甚至是痛苦，但作完以後回過頭看，才發現已經前進了很遠了。

將來規劃

你究竟想成爲一個什麼樣的人？

這是我離開公司以前 mentor 跟我說的一句話，讓我回去好好想一想。我一時間想不出答案，也許這個問題還得圍繞我很長時間，這裏我暫且梳理一下以後的一些方向吧。

深耕專業技能

無論怎麼說，當下最重要的事情仍是提高本身的專業水平，不管是具體的技術棧，仍是對架構設計的理解，我以爲都有不少地方須要增強。

曾經有一天我問旁邊工做了不少年的大佬，你的 node 代碼爲何寫的那麼漂亮？他的回答很簡單:

多看多寫就好了。

這不由讓我忽然想起狼叔曾經也對尤大作過一個採訪，他問尤大，你爲何能在 vue 中寫出那麼多巧妙的邏輯，並且把 git 當中那麼多 tricky 的技巧用的駕輕就熟，你是怎麼作到的？尤大當時也是相似的回答，常常看開源項目，也許是專門抽出來的半小時，也許是喝下午茶的十分鐘，不斷從別人的項目當中學到編程思路，豐富本身的"武器庫"，日積月累，就能夠漸漸提高本身的水平了。

讓本身變得更加專業，設計出更加高質量的代碼，須要很長時間踏實的積累，沒有捷徑能夠走，若是非要說有捷徑，那就是站在巨人的肩膀上，多看優秀的代碼，從中得到一些想法，而後多動手來印證本身的想法。

增強時間管理

工做以後，才發現有效地管理本身的時間和精力是多麼重要，並且若是不刻意地去改善，很容易被動地陷入到工做無盡的忙碌當中，難以脫身出來。

我以爲須要從兩點着重入手，第一是學會作減法，之前什麼都想碰一下、什麼都想學一下的念頭到如今是時候被捨棄掉了，有限的時間，須要被花在刀刃上，想作的事情太多反而會讓本身分心，不如讓本身集中在某些少許且重要的事情上。第二是提早作好規劃，這樣能充分利用碎片的時間，不至於漫無目的，閒下來不知道作啥而致使大量碎片的時間被白白浪費掉。

多輸出、分享

過去一年輸出、分享的頻率明顯下降了，一方面的確有工做繁忙的緣由，但另外一方面，也是由於本身自己的惰性，沒有主動去思考和作計劃。

我並不以爲這是一個很好的徵兆。

畢竟以前和社區知名做者ssh聊過，不少技術水平很高的人是不怎麼寫文章搞分享的，但咱們能夠寫出這麼多的東西，並非由於技術有多強，而是咱們性格自己就是樂於分享的，而碰巧又有不少人喜歡咱們分享的東西，給某些人帶來了幫助，因而分享輸出這個事情給咱們附帶了一些影響力。

其次，做爲一個原創的技術博主，我也深知輸出就是一個倒逼輸入的過程，好比寫包管理器，覺得看了官方文檔就弄明白了，真正要寫的時候才發現本身有那麼多的知識盲點，npm 包管理的缺陷、依賴安全問題、社區的depedency-check 方案，這些都是我在寫文章的過程當中經過查閱資料一個個瞭解到的，以前甚至都沒有涉獵過。因此輸出的過程不只僅是讓讀者受益，對於做者自己的知識體系也是一個錘鍊和拓展的過程。

一方面本身自己就樂於分享，另外一方面分享也能倒逼學習和成長，因此我以爲這個事情頗有必要堅持作下去。

最近關於工程化的輸出正在逐漸變多，將來會更頻繁地和你們見面，輸出內容也會逐漸多元化，再也不限於前端，也會包括本身工做當中的思考、讀書心得(這些會放到公衆號裏面，掘金以技術輸出爲主)，敬請期待吧。

關於團隊

以前有不少讀者對字節前端架構如今作的事情很感興趣，我就先以本身目前所在的工程化團隊來介紹一下吧。

團隊工做涉及包括：

• 基礎工程化框架的建設，包含初始化、構建、調試體系、CI、CD，中後臺研發框架(相似 umi)、以及代碼質量相關的掃描平臺
• nodejs 基礎庫的建設
• 可視化搭建平臺的建設
• 全公司資源分發平臺的建設

團隊的技術氛圍仍是挺不錯的，雖然有的是異地辦公，但在羣裏你們仍是常常討論和分享一些技術方案，週會的時候也會常常有各個方向的技術分享。組裏的技術大牛仍是不少的，若是有問題，他們也會很耐心地幫你答疑解惑，經過和他們的共事也能夠學到很多東西。

平心而論，團隊如今仍是至關缺人的，尤爲是神三元同窗如今所在的工程化框架的團隊，咱們也時常由於人力不夠的問題而暫停了某些技術的進展(像以前說的 SSR 框架)。若是你對上面的這些方向也感興趣，很是歡迎來和咱們一塊兒建設公司的明星級技術產品。

最後我要強調的是，不少人和我聊的時候，我發現你們看到字節面試，就會下意識地以爲會出很是難的算法題，或者直接手寫紅黑樹這種變態的編程題，這種見解是極端錯誤❌的！一方面是我如今的組並無你們想象那麼內卷，反而是團隊搭建不久，更加須要新鮮的血液融入進來，出那種故意刁難候選人的題目壓根沒有任何意義；另外一方面整個團隊也是很是務實的，看重我的實實在在的工程能力和學習能力(潛力)，那種跟平時工做八竿子打不着的問題咱們也不會拿來爲難候選人。

若是有意向或者對崗位還有疑問的話能夠直接聯繫我，個人微信號是 sanyuan0704，固然單純的交個朋友也歡迎啦。

文章首發於「三元同窗」公衆號，歡迎關注。回覆"JD"可得到職位描述，回覆"IES"可進入「字節跳動 IES 預備招聘羣」進羣方式，你們一塊兒學習、精進。