我們常說要傾聽基層人員的聲音，因為他們才是真正在做事的人，在開發上也一樣。
不過成為 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 的一些感想」一文當中，我發現自己已經沒有那麼在意有沒有加薪這件事了（但還是會在意），一方面是因為我對現在的職位以及工作模式與內容都算滿意、一方面是體會到每個人都有自己的工作模式，把自己的本分做好無愧於心就好。
可能私底下在推特上還是會抱怨個幾句，但還是會想要盡可能提高團隊生產力，繼續改善原有的開發流程與專案。
