在 Shopee 當 Backend Developer 是個什麼樣的體驗?

small2kuo
15 min readJun 7, 2020

--

筆者在新加坡 Shopee 當了差不多三年半的後端工程師,現在是某個產品子線的 team lead 帶有六人小團隊。從加入只有約莫50人到現在近千人,親眼見證也一同參與了 Shopee 的改變與成長,自認為對於 Shopee 的工作環境與後端工程師(BE dev)職涯有比別人多一點的理解,希望藉此讓有興趣要來 Shopee 當 BE dev 的朋友能多了解這邊的狀況,也可以評估一下這裡的文化跟你想像中的一不一樣。

這篇文章會只針對 Shopee 的 BE dev 以我個人經驗與觀點來描述,如果有些覺得感受不同的歡迎討論,又或者對於其他 team 有興趣也可以在下方留言或我幫你找人回答。

以下文章會先從下列順序來講述:

  • Shopee 工程師文化
  • BE dev 工程師的職涯想像
  • 最後會結合兩者來討論在 Shopee 當 BE dev 的挑戰與成長會是什麼

Shopee 的工程師文化

新加坡 Shopee 總的一句話來說就是重工程師的一家中資半新創公司,工程師們有著許多的自由度與備受尊重。而半新創指的是我們有著新創的自由、衝勁、與年輕肉體(?)。另一方面也慢慢朝著大公司有的完善的制度與架構,好處是分工慢慢細化,不太需要處理太多細節,但相對溝通的成本也越來越高,部門之間合作也越來越趨複雜。

團隊

Shopee 目前有兩大開發團隊分別在新加坡與深圳,而部門分法是照業務線來分,一如筆者現在就是屬於 Order(訂單)這個部門的後端工程師,當然還有其他業務線例如 Promotion、Payment 等等這些產品線的後端工程師。剩下的類似後端工程師的還有幾類,分別是 Server(負責處理核心共同業務邏輯。中國一般叫這個中台,源自SuperCell的組織架構¹),架設 Platform 的工程師,與 Data Engineer(DE,建立 Data Warehouse 與 Pipeline)。我們的 Server 也有分產品線,而 Platform 主要就是架設給我們工程師用的平台(可能有部分與所謂 DevOps 有些重疊),但本文不會在此多做琢磨,還是主要先談談 BE dev 的生態。

2018 年參加公司舉辦的 Hackathon

開發流程

公司產品迭代速度非常快。工具上是使用 Atlanssian 的 Jira 與 Confluence。我們沒有業界常聽到的 Agile 或 Scrum 而是自己用自己的一套開發流程,但每週發版一次也代表我們的開發速度極快,而且現在寫的東西很快就會被使用者所碰到。雖然比起我剛來想發佈就發佈,現在速度已經慢了許多,但從每個人同時都會有好幾項 ongoing 的 tasks 與排到一兩個月後的開發排期,就可以感受到這邊的工作步調是非常緊湊的。除此之外,為了能隨時處理意外的發生,大家的反應速度也都被訓練成要能快速反應變化,舉個簡單的例子說,常常國家政策的改變都是說改就改,公告期幾週就要上線,為了能做到這些,產品經理(PM)與工程師都被訓練成能對於緊急的狀況能即時反應與快速開發完成。當然這樣的背後其實也代表偶爾會要加班與為了即時解決問題很容易有技術債的產生。

技術

使用技術方面可能跟許多中國公司很像,都會開發一套的內部系統或者修改 一些 open source 的 project 拿來處理自己的應用場景。簡單列舉一下我們這邊BE的會碰到的 tech stack(DE 碰到的 stack 跟我們差蠻多我就不在這邊列出)。語言方面是 Python 2 (Django)+ Go,存資料相關的是 Mysql、TiDB、Kafka、Redis Cluster,還有一些 DevOps 幫我們處理好的例如 Mesos / K8s、Rundeck / Jenkins、Prometheus / Grafana。另外還有許多自己內部用的 tool 跟 microservice system 我這邊就暫且不提。

職涯成長與培訓

我們內部每週都會有一兩次的技術分享與 soft skill的課程,自由報名參加,錯過也有影片跟 slide 可以參考。而每個 team 內部的分享就是看 team 本身了。至於你想去參加上外部課程或者去參加國際的 conference 來精進自己能力,公司基本上會看與工作的關聯性來決定補助金額的多寡,例如之前Pycon TW 我們就有不少台灣人通識拿了補助回去參加。我自己比較沒用到這部份資源,但是有同事用蠻多的覺得很不錯,所以也是可以考量一下這部份的福利。

我們 team 的某次烤肉活動

團隊組成

依據 team 的不同有著不同的人種組成,我自己所在的team有台灣、馬來西亞、印尼、中國、新加坡、越南、伊朗、泰國、印度…等東南亞各國的人,但 PM 裡中國人就佔了蠻高比例。平時溝通基本上還是英文,但如果大家都懂中文也是可以直接用中文討論。筆者自己英文不是特別好,來之前不太能完整用英文跟別人溝通,但是待久了自然就習慣了現在還可以聽懂各國口音 + 主動用英文分享知識。整體來說,我覺得語言對工程師來說影響程度並不那麼大,公司對於工程師的語言能力要求也並沒有非常高。

我們最常溝通的人員除了其他工程師外非 PM 莫屬, PM 是我們業務團隊的溝通的橋樑也是規劃產品需求的決策者,但基本上在這裡的 PM 都是非常尊重工程師的,常在靠北工程師上聽到的 PM 對 dev 的惡劣關係或頤指氣使我自己是從來沒遇到過,我自己也是很喜歡跟 PM 們玩在一起跟講垃圾話。其他常溝通的人還有測試員 Quality and Assurance(QA) 跟專案經理 Project Manager(PJ),這部份想必哪裡都差不多我就不多闡述。

工程師職責與工作

在職責上,我們目前工程師是需要同時做開發與維護,正所謂「自己的 bug 自己修」。相較於有些公司會把這兩部分拆開,我並沒有真的經歷過另一種模式所以無從判斷。但就我所知目前感覺還尚未有這種規劃,想來這也是造成我們工程師開發常被打斷或排期時程有些混亂的原因之一。我們有個 On Call 的制度是 team 內 member 會以週為單位輪流值班,基本上責任是要接電話且當有東西壞的時候要找到人去處理(不一定要是自己),但跟上述所說的開發維護分離還是差別蠻大。另外,除了開發維護,公司也期待你能有越高的自治力與主動性,需要從跟 PM 討論需求、發想一些 tech project 或 improvement、甚至 conduct 整個 feature,而這些其實也是公司對於 senior 的更多期待。

小結

簡短小結上面說的幾項,半新創的架構帶來自由度高且學習機會多,只是要從混亂中摸索,衝刺快速但相對不穩。所有的事情都是一體兩面,上面列出的幾點讀者應該可以看出有好有壞,但你能不能接受其實就是端看個人。我當初來到 Shopee 做為第一份正式工作,並沒有特別對於工作的想像,遇到什麼就接受什麼,所以都沒有什麼特別不適應的地方。但每個人重視的東西不同,每個現象背後是好是壞我就留給讀者自己決定。

Backend Developer 的未來

在我說我自己的想法前,希望大家可以先想想,你們對於 BE dev 的想像是什麼?期待是什麼?應該要會那些技能?可能會遇到什麼困難?當 BE dev 有什麼前途😆。

從我自己的經驗來說,一直到我自己在加入 Shopee 之前,對 BE 其實沒什麼太大的興趣,覺得 BE dev 就是學學新的語言跟使用不同的 framework,或者不同的資料庫 Database(DB)來架設網站,沒什麼大不了的,還是做跟應用演算法有關或系統底層有關的東西有趣許多。但來了之後一路從 junior 到 senior 再到現在的 team lead 覺得 BE dev 這個職位的博大精深遠遠超出我的想像。

某日晚上大家一起訂 pizza + 打電動

某種程度來說,科技公司的誕生都是會了把一個現實生活的問題 對應到使用電腦科學的技術去解決。如果你解決的問題 scope 小,的確是看到的 BE就是這樣子沒錯,但是如果你解決的問題 scope 大,例如說 Shopee 這個平台誕生其實就解決了線下拍賣/購物的麻煩,那這 scope 就是不同等級的事了。因為問題本身的狀態越來越多,要儲存的資料也量會越來越大,系統除了可以動之外,考慮到的面向也會越來越多。要如何建構「好的」系統就變得非常困難。這裡的「好」包含了很多面向,Reliability、Scalability、Maintainability²、Performance、Security…,下面將用我三年前開發的發票系統來簡單說明。

當時大部分service都是在一台機器上(monolithic),因為業務量不大,開發票的過程基本上就是 scan DB,開出對應的發票,然後存對應的狀態到 DB 裡,Done!先不論我的糞 code 寫的如何,整個流程其實建立在很多的假設上但我當時卻不自知,直到最近我們慢慢從 monolithic 架構搬到 microservice 上,變發現事情大條了。因為我們的 service 能提供的 reliability 與performance 與 DB 能提供的完全不同等級,讀取訂單的 table 壞掉的機率瞬間倍增,除此之外因為資料量越來越大,到後來一天的發票要跑八個多小時,時間長了壞掉的機率就更高了。

在重構的過程中考慮到了許多東西,哪些地方是真的需要 transaction 的?哪些地方失敗了是要直接 retry?如果真的不幸失敗的時候要怎麼快速的修復的?是否可以利用一些 event driven 的方式去先產生好 data 而非去 scan table 的?諸如此類的問題。除了技術問題之外,還有更重要的事情是業務切分的份,這個發票系統未來要支持更多的產品,例如付費廣告 paid-aids、數位商品 digital product 等等,要怎麼樣建立清楚分界哪些是這個「開發票服務」本身要處理的哪些是 client 要注意的…等等事物。

在現實世界裡永遠沒有最優解,每個作法都有它的利弊存在,重點是在不同的方案中做出權衡,並預測未來有可能的變化,然後做出決定。

認真工作的大家

這件事情的難處不只是技術的限制,更多是現實上的考量,我們都想要用最少的 effort 做出最好的系統,但人力就是不足、時間就是很趕、資源就是不夠、需求端就是不買單,所以在既有的限制下做出最好的決定加上未來的規劃,我覺得這個就是我們 BE dev 的價值所在,或著講的厲害一點,就是所謂架構師(Software Architect)的存在價值。大一點的系統上就是 Distributed System 的課題,小一點的就是 Operating System 的難處,要做出的好抉擇都是需要有些背後的研究結果支持的,這也是我當 BE dev 覺得最有趣的地方,因為其實還是有著非常多的發展與可能性存在的。

在 Shopee 當後端工程師的體驗

所有事情都是一體兩面,我在第一段列出的環境與文化,想必讀者已經能看出許多優缺點存在。以下我從幾個面向來列出我覺得在 Shopee 當 BE dev的優缺點。

公司開放空間一隅

學習與成長

對 junior 來說這裡其實有蠻多機會可以讓你嘗試與練習,更重要的是容許你犯錯,而我自己覺得要成長最快的途徑就是不斷的嘗試與犯錯😆(至少我就是這樣一路走來的)。這裡的 BE team 都還蠻 自由可以讓你做幾乎任何想做的嘗試,且 team lead 或 manager 也會跟你討論嘗試的細節與可行性,藉此來獲得許多的成長。只是有一個壞處是我覺得我們這邊大家相對年輕,所以有經驗的人相對少很多,比較會是「跟你一起發想跟討論要怎麼樣做到最好」,而比較不是「有直接的經驗可以跟你說怎麼做比較好」,另外因為大家也都蠻忙碌,所以能否獲得足夠的 guidance 可能就是要看 team 有沒有這樣的人力資源。

而對 senior 來說一開始的挑戰會是要花時間適應這裡的文化與了解我們比較混亂的架構與產品,但一旦你能把這些掌握的很好之後便能有蠻多發展性跟主導權的。加上機會很多跟自由度高,所以應該是蠻有機會像我一樣成為小 team lead 來學習 manage 各種 project 甚至整個 product。不過如果是在成熟大公司的 senior 來到我們這邊可能會有些不適應,因為很多事情或制度的不完善還是需要自己 hands-on 的處理可能是要注意的地方。

另外講一下上面提到說公司蠻多內部系統(例如我們自己架設的microserver 平台),學習這些系統怎麼用好像沒啥屁用,畢竟出來了又無法用在其他地方。我自己覺得這件事對我來說還好,畢竟你看到一個系統,你除了學習他怎麼用之外,更重要的是他背後這樣做的原因與他帶來或解決了什麼樣的問題。就像你學 framework 跟語言不也是差不多?技術本來就會不斷成長,現在學的東西可能過幾年後就不管用了,在科技業特別是如此。重點是你看到了多好的抽象,多漂亮的寫法,或者產生了哪些問題,進而能否把這些經驗用在其他地方。

9.9 Shopee Day 值班人員合影

挑戰

因為資料量大所以隨之而來的問題跟要考慮的細節就隨之倍增³,好處是可以訓練你去思考計畫與處理到各個面向,當然壞處是問題很多(或很急)的時候會很煩😅。我自己身在 Shopee 看這業務量從小一路走到大,跟著流量成長也慢慢學習 Distributed System 的知識與發現挑戰,比起某些公司一開始就是處理大流量的架構或者流量一直都很小,這種經驗真的是少有且難能可貴的。

另外需求方面因為 team 的不同所以也會有些許的差別,有些人比較喜歡單純技術上的需求與挑戰,有些人喜歡能夠落地或直接碰到使用者的產品,而碰到使用者又有分直接影響(例如下單 Checkout ),與間接影響(例如下單後的 Order Fulfillment )。每個 team 都會有一些自己的 speciality,自己能不能接受就真的蠻看有沒有辦法適應每個小 team 的文化,不過如果真的不適應想調轉到不同的工程師的 team 也是有機會的。

2019 年聖誕節 team 內的交換禮物

薪水待遇 & 工時

這部份可能是大家最在意的部分😆。我自己沒有去過其他公司,無從比較好壞,而且我最重視的其實就是自己有沒有辦法成長,至於其他的福利什麼的可能對我來說 minor 一些(當然也可能是因為我有些部分是既得利益者,所以身在福中不知福😆)。就我感覺,只要你能與公司文化 perfect match 的話,公司對工程師是蠻敢給的,可能比不上大家所謂的一線大公司例如 Google、Facebook,但至少這部分我還算是滿意的。

工時方面可能對某些人來說有點長(官方表定是 10 a.m. 到 7 p.m.,午休1.5 hr. ),而且偶爾要加班,但我自己本來就蠻工作狂,只要做的事情覺得有趣與有意義的,我基本都還是可以接受的。

小結

最後如果問我整體在這家公司當 BE dev 的感覺為何。從第一年剛畢業一個不太會寫大系統 code 的 junior,到第二年熟悉整個架構且比較知道怎麼 manage 一個 project 的 senior,到第三年終於當上 team lead 要處理整個 product 與管理整個小 team,一直是有感受到可成長的部分。一路走來公司的走向也蠻契合我的需求,這也是為什麼我會持續待著的原因吧。

結語

以上就是對於 Shopee BE dev 的介紹。大致從公司文化,BE dev 的角度介紹了一輪,希望對於選擇要不要來敝司能多點幫助,如果有哪裡講不清楚或者想知道某些細節的,可以再留言跟我說。

Shopee 台灣人排 TW 合照

最後,還是要說一下覺得自己是無比幸運的例子,能跟著 Shopee 一起成長,也能都遇上很好的老闆跟同事們,也能備受尊重與重視,雖然有時候要加班跟處理鳥事,但整體來說都還是開心的。至於推不推 Shopee BE dev,對 new grad 來說是蠻推薦的,但 senior 就真的見仁見智了,畢竟每個人能接受的文化都不太一樣。也祝福各位碼農們能找到適合自己的公司😇。

對於其他 team 有興趣或新加坡生活的話可以參考幾篇強者我同事寫的文章:

[1] 史凯 (2020, May 11) SuperCell 的中台你们学不会. Retrieved from https://www.infoq.cn/article/csTfCNvzQzQZRV8sxPqz

[2] Martin Kleppmann (2017). Chapter 1. Reliable, Scalable, and Maintainable Applications. Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems (pp. 3–26). O’Reilly Media.

[3] Martin Kleppmann (2017). Chapter 8. The Trouble with Distributed Systems. Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems (pp. 273–320). O’Reilly Media.

--

--

small2kuo
small2kuo

Written by small2kuo

曾經以為自己是技術人,但後來發現幫助人才是自己的天職的碼農,深信用愛可以改變世界。曾待過新加坡電商,目前旅居愛爾蘭。兼職Life Coach與Career Mentor。