融雲猿桌派備忘錄,那些被程式設計師 Pick 的工作方式

融雲RongCloud發表於2022-03-23

3 月 10 日,“猿桌派”第 2 季第 1 期正式開播!關注【融雲全球網際網路通訊雲】瞭解更多

節目主理人融雲技術 VP 臧其龍與 Grab 高階研發宋清晨、VMware iOS/MacOS 開發尚傳人就“中外網際網路公司面面觀”展開討論。

嘉賓觀點集錦

臧其龍 融雲技術 VP,曾任職 Musical.ly(TikTok 前身)、英語流利說、Grab 等中外知名企業,擁有 10 年以上前端研發經驗,精通視訊特效處理,前端架構設計。

我們在剛步入職場時,不可避免地會有些疑惑, 為什麼要做這個東西?感覺跟使用者毫無關係,鏈路隱藏得很深。

以現在的視角來看,我會覺得當時的自己沒有把工作放在整個公司的架構和目標上去看。目標細拆之後,落到你身上,可能很不起眼,但其實非常關鍵。所以即便是一個基層員工,也應該瞭解整體目標和計劃。


宋清晨 Grab 高階研發,曾在國內知名房屋買賣公司從事 iOS 開發,後加入東南亞網約車和送餐服務巨頭 Grab,伴隨公司一路發展壯大。

我認為,我們寫出來的東西需要更易於每個人理解。每個人提交的程式碼,不同研發中心的成員站在不同視角,甚至不同國家去看,能識別出很多問題。

大家目的一致,都為了當前的業務。這樣,為了更好地合作,大家的程式碼習慣會默默地往這個標準上去靠近,其實就保有了一種比較好的共識默契。



尚傳人 VMware iOS/mac OS 開發,研究生畢業就進入猿輔導從事 iOS 研發工作,近期入職全球雲基礎架構和移動商務解決方案廠商 VMware,開啟新旅程。

加入猿輔導時,公司最吸引我的就是強制性的 Code Review。我覺得 Code Review 是所謂工程師氛圍很重要的一點。在職業生涯初期,進入一個 Code Review 比較嚴格的團隊對個人發展是非常有利的。

應屆生或在校時寫程式碼的要求是能跑就好了,要求 workable,而在公司裡,你的程式碼需要跟別人合作,要 maintainable,這兩個單詞就決定了對程式碼要求完全不同。

精彩內容回顧

中外網際網路公司面面觀之程式設計師喜歡的工作氛圍和組織形式盤點:

成為自己產品的重度使用者

鼓勵包括程式設計師在內的所有同學成為自家產品的重度使用者。

以 Grab 為例,公司服務主要面向東南亞地區,但會讓其他地區的員工也有機會去到業務和市場所在地實際體驗產品,甚至參與點餐、送餐和後續的客戶服務等環節,更深入地理解業務。

另外,公司鼓勵開發人員瞭解自己所開發功能的背景,而不是單純接受一個任務。

對齊目標,達成共識

注重 Big Picture 大場景的同步,每個季度通過全員會等形式,跟大家同步工作進展。

作為一個普通工程師,當知道你做的工作是跟大目標目標統一的,成就感和方向感會非常強。公司從高層開始就可以把大目標一層層往下推進,雖然每個人可能只做其中的一個小點,但是要跟公司的大目標是對齊的。

否則,可能造成對自己做的事情與公司目標之間關係理解不透徹的情況,也就沒辦法產生價值認同。

工程師也要進現場

大部分場景下,程式設計師也需要非常深入地體驗和了解業務,進現場很關鍵。

即使做技術架構,也需要進到一線工程師裡面去收集痛點,這樣做出來的東西才能落地。

以融云為例,融雲去年推出了語聊房、直播等一系列第三代場景化 SDK,在 API 設計上要求簡潔、貼近業務,以期最大限度降低開發者的學習門檻和成本,提升開發效率。

融雲的每個 SDK 在推出前,都經歷了大量“進現場”過程,聽取客戶在接入過程中的反饋,抽取出通用能力,總結出最佳實踐提供給開發者。

文件先行,測試隨行,留有 Buffer

在做一個 Feature 時必須文件先行,先把設計思路寫下來。一方面能夠把事情理清楚,另外一方面方便後面的人理解整體設計。

過程中要求單元測試要求的覆蓋率至少 50% 以上,儘量讓這個過程自動化起來。

整體在任務排期上不會卡得特別死,Deadline 依然是第一生產力,但會留有一定 Buffer,更人性化。

新技術大膽嘗試、小心求證

在技術選型方面,面對新興技術,國內企業稍顯保守,國外企業對新技術的使用會更大膽一些。

比如 Grab 對於 Swift 的選擇,會跟工程師們一起探討、驗證,Swift 從安全性、效率性、可讀性等方面在開發類似功能上都超過 OC,做出綜合評估與報告之後決策。

小心求證,大膽嘗試。


程 序 員 請 上 桌

相關文章