半熟前端

軟體工程師 / 台灣人 / 在前端的路上一邊探索其他領域的可能性生活部落格

雜談

Tech Lead 守則 1 — 深入基層

Tech Lead 守則 1 — 深入基層

我們常說要傾聽基層人員的聲音,因為他們才是真正在做事的人,在開發上也一樣。

不過成為 Tech Lead 除了了解程式碼本身之外,更重要的是必須要對整個專案有通盤性的了解,以下列出幾個我覺得很重要的地方。

前言

一年前曾經寫過「成為 Tech Lead 的一些感想」,這一年當中學習到的很多事情,最近也發了一篇「在公司中架設 Server 沒有我想像中的那麼簡單」,這篇文章算是把自己認為當 Tech Lead 所要具備的事情梳理一遍,當作筆記。希望也能夠幫助到正煩惱 Tech Lead 該做什麼才好的讀者。

專案裡使用了哪些框架、技術

以前端來舉例:

  • 有沒有使用前端框架,他們的新版本與特性為何
  • 是否對應 SSR
  • API 是如何串接的,GraphQL、RESTful API 還是 gRPC?
  • 對後端使用的程式語言與架構有粗淺的了解

通常能夠被指派為 Tech Lead 的軟體工程師,代表被交付的任務能夠順利完成、能夠協助專案解決問題、能夠掌握團隊進度,至少代表寫程式上沒有太大的問題。既然在專案裡頭以 IC(Individual Contributor)的方式貢獻,那麼這部分是沒有太大問題的。

至於為什麼要了解後端使用的程式語言與架構,因為會跟前端緊密配合的除了設計之外就是 API 的串接了,了解對方現行架構下遇到的問題,或許可以和後端討論出更適合的方案,甚至還能夠幫助對方解決問題也說不定。

專案中重要的業務邏輯有哪些

在金融服務當中,一些重要的業務邏輯包含,如何執行扣款、時機點為何、如何確認使用者身份、個人資料應該如何保存等等。對於前端來說,這些往往都是後端應該處理的事情,但理解背後的運作機制就是為了未來的需求做準備。

處理金額比較大的顯示時,是否有用 BigInt 避免溢位、貨幣轉換是是否充分注意浮點數問題、小數點進位是在前端處理還是後端,對於時間處理是否有嚴格要求(必須為標準時間,使用者無法任意調整等),這些都是涉及金融服務的專案當中相當重要的一環。

在理解業務邏輯的同時,通常也需要開發者了解這方面的領域知識,甚至在金融服務當中還需要稍微知道要注意的法律有哪些。

專案如何被部署

雖然和專案開發本身沒有直接關聯,但是知道程式碼是怎麼被部署的,對於推動各種流程改進是相當有幫助的。

假設目前的專案是用 Docker,首先先將專案打包成 image 後,接下來會上傳到公司私有的 docker hub,然後部署的機器再去 pull 並且執行。

這裡就有很多地方值得注意,image 是由誰執行上傳動作、token 是在哪裡設定的、部署的機器 ACL 是否可以通到 docker hub, token 是如何傳遞的。 雖然這些超出前端的守備範圍很多,但了解越深,越能夠達成自己想要推動的事。比如說想要開新機器導入 SSR,先前已經知道部署流程為何,可以很快知道腳本要怎麼寫,哪些地方可能碰壁並事先著手處理。

除此之外,也可以觀察部署的時間進而改善流程,比如說每次 image 當中都要重新安裝相依套件,加長了部署時間,這時候就可以試著將共同的部分拆出另外打包成 image 減少安裝時間,整體的部署時間就可以加快。

請求發出到伺服器接收的整個流程

  • 是否會經過 load balancer
  • 在正式環境當中有幾台機器,各自的 spec 分別為何
  • 機器部署在哪個區域
  • 靜態檔案存放在機器還是 CDN
  • 是否有反向代理(nginx 或 envoy)

    • 是否有特殊的 rewrite/redirect 規則需要了解
  • 伺服器開在哪一個 port

了解歷史

有時看到爛扣心中的 OS 會開始咆哮:「為什麼要這樣寫?WHY???」,撇去「我就爛」的那種爛扣之外,最近也學著去理解背後的歷史。有時候是因為時程太趕、有時候是因為業務需求實在太奇葩又跟現有架構不合、有時是因為架構演進時所做的權衡。一旦往歷史的角度去想,有時候反而會感到佩服。

了解各方需求

有時候專案上發生衝突,除了溝通失調之外,很多時候是因為不知道彼此在意的事情是哪些。舉例來說,某個專案的時程莫名其妙被拉得很緊,開發者每個人都為了趕時程壓力很大,心裏卻認為只是 PM 單方面地想要壓縮開發時間而已。但是事實上是,因為這個專案牽扯到新法規制度,必須趕在新法規之前發布完成,不然很可能因為違法被罰款。

像是這些事情,有時候並不是刻意隱瞞,可能是沒有把訊息讓全部門知道,或是中間忘記傳達。

我覺得這時候很重要的一點是,相信對方的問題是問題。可能在開發者眼中這個問題很蠢,或是聽起來很不合理,但如果以「大家都是想要這個專案變得更好」這個角度出發,那麼得出來的結果相信也會完全不一樣。(除非真的是存心想找麻煩)

另外一點就是有問題就提出來,大家都覺得多問問題沒關係,問笨問題也沒關係,但很多軟體工程師可能自尊心比較強,害怕真的問問題後反而被打臉,所以就算心中怒火狂燒還是默默把功能做完。這時候往往一個提問或是多一點確認就能化解危機(如果不行的話......,應該知道怎麼做了吧)。

總結

這些事情之所以重要的原因,不僅僅是因為你是 Tech Lead 所以應該要了解而已,這些事情可以幫助你在遇到新專案、新需求或是團隊當中出現瓶頸時,如何有效運用現有的資源解決問題。

對於新的需求或改善,開發的速度與品質往往取決於對既有架構的理解,今天可能有新的需求是上傳圖片並且產生 thumbnail,假設在某某功能當中已經有類似模組,只需要對既有功能做修改即可,但因為 Tech Lead 沒有掌握這件事,可能造成的結果是花上更多時間與資源。

團隊們也會時常與 Tech Lead 討論各種 Technical Decisions 或是針對某某需求的實作,上述提到的事情都是幫助你提出見解的好材料。只有真正深入架構,了解開發人員遇到的難題,釐清彼此的需求,才不會讓新的需求或解決方案淪為天馬行空。

後記

在一年前的「成為 Tech Lead 的一些感想」一文當中,我發現自己已經沒有那麼在意有沒有加薪這件事了(但還是會在意),一方面是因為我對現在的職位以及工作模式與內容都算滿意、一方面是體會到每個人都有自己的工作模式,把自己的本分做好無愧於心就好。

可能私底下在推特上還是會抱怨個幾句,但還是會想要盡可能提高團隊生產力,繼續改善原有的開發流程與專案。

如果覺得這篇文章對你有幫助的話,可以考慮到下面的連結請我喝一杯 ☕️
可以讓我平凡的一天變得閃閃發光 ✨

Buy me a coffee