我們常說要聆聽基層人員的聲音，因為他們才是真正在執行工作的人，開發也是如此。
不過，成為 Tech Lead 除了了解程式碼本身之外，更重要的是必須對整個專案有全面的了解，以下列出幾個我認為很重要的地方。
前言
一年前曾經寫過「成為 Tech Lead 的一些感想」，這一年中學習到了很多事情，最近也發了一篇「在公司中架設 Server 沒有我想像中的那麼簡單」，這篇文章算是把自己認為作為 Tech Lead 應該具備的事情整理了一遍，當作筆記。希望也能幫助到正在煩惱 Tech Lead 應該做什麼的讀者。
專案中使用了哪些框架、技術
以前端為例：
- 是否使用了前端框架，新版本和特性是什麼
- 是否支援伺服器端渲染（SSR）
- API 是如何串接的，GraphQL、RESTful API 還是 gRPC？
- 對後端使用的程式語言和架構有基本的了解
通常能夠被指派為 Tech Lead 的軟體工程師，代表被交付的任務能夠順利完成、能夠協助專案解決問題、能夠掌握團隊進度，至少代表在寫程式方面沒有太大的問題。既然以個人貢獻（IC）的方式參與專案，這部分是沒有太大問題的。
至於為什麼要了解後端使用的程式語言和架構，因為除了設計之外，與前端緊密配合的另一個方面就是 API 的串接。了解對方目前所遇到的架構問題，或許能夠與後端討論出更適合的解決方案，甚至能夠幫助對方解決問題。
專案中重要的業務邏輯有哪些
在金融服務中，一些重要的業務邏輯包括如何執行扣款、時機點是什麼、如何驗證使用者身份、個人資料應該如何保存等等。對於前端來說，這些通常是後端應該處理的事情，但理解背後的運作機制是為了未來的需求做準備。
處理較大金額的顯示時，是否使用了 BigInt 來避免溢位問題，貨幣轉換是否充分考慮了浮點數問題，小數點進位是在前端還是後端處理，對時間的處理是否有嚴格要求（必須使用標準時間，使用者無法隨意調整等），這些都是涉及金融服務專案中相當重要的一部分。
在理解業務邏輯的同時，通常也需要開發者了解這方面的領域知識，甚至在金融服務中還需要稍微了解需要注意的法律。
專案如何部署
雖然和專案開發本身沒有直接關聯，但了解程式碼是如何被部署的對於推動各種流程改進非常有幫助。
假設目前的專案是使用 Docker，首先將專案打包成映像檔（image），然後上傳到公司私有的 Docker Hub，接著部署機器會從 Docker Hub 拉取並執行。
這裡有很多值得注意的地方，例如由誰執行上傳動作、token 是如何設定的、部署機器的存取控制清單（ACL）是否能夠連接到 Docker Hub，token 是如何傳遞的。雖然這些超出前端範疇的設定很多，但了解得越深入，就越能夠實現自己想要推動的事情。例如，想要在新機器上實施伺服器端渲染（SSR），如果已經了解了部署流程，就可以迅速知道該如何編寫腳本，並提前處理可能遇到的問題。
此外，觀察部署時間也可以改善流程，例如每次映像檔中都需要重新安裝相依套件，延長了部署時間，這時可以嘗試將共用部分拆分為另一個映像檔，減少安裝時間，從而加快整體部署時間。
請求從發送到伺服器接收的整個流程
- 是否經過負載平衡器（load balancer）
- 在正式環境中有幾台機器，各自的規格是什麼
- 機器部署在哪個區域
- 靜態檔案存放在機器還是 CDN
- 是否有反向代理（例如 nginx 或 envoy）
- 是否有特殊的重寫/重新導向規則需要了解
- 伺服器開在哪個埠（port）
了解歷史
有時候看到糟糕的程式碼會開始抱怨："為什麼要這樣寫？為什麼？？"，除了那種自嘲的抱怨之外，最近我也學著去理解背後的歷史。有時候是因為時間緊迫，有時候是因為業務需求很奇特且與現有架構不符，有時候是因為架構演進時所做的權衡。一旦從歷史的角度去思考，有時候反而會感到佩服。
了解各方需求
有時候專案中會發生衝突，除了溝通失調之外，很多時候是因為不知道彼此在意的事情是什麼。舉例來說，某個專案的時程突然變得很緊湊，開發者每個人都為了趕時程而感到壓力很大，但他們心中卻認為只是 PM 單方面想要壓縮開發時間而已。然而事實上，這個專案涉及到新的法規制度，必須在新法規生效之前完成，否則可能因違法而受到罰款。
像這樣的情況，有時並不是刻意隱瞞，可能只是沒有將訊息傳達給所有人，或者在中途遺忘了傳達。
我認為在這種情況下，相信對方的問題是問題是非常重要的。雖然在開發者眼中這個問題可能看起來很蠢，或者聽起來很不合理，但如果從「大家都希望這個專案變得更好」的角度出發，得出的結果相信會完全不同。（除非有人故意想找麻煩）
另外一點是有問題就要提出來，大家覺得多問問題沒關係，問一些看似愚蠢的問題也沒關係，但很多軟體工程師可能自尊心較強，害怕提問後被指責，所以即使心中憤怒仍默默完成功能。然而，有時候只需要提出問題或多做確認就可以化解危機（如果不行的話......，應該知道該怎麼做了吧）。
總結
這些事情之所以重要，不僅僅是因為你是 Tech Lead，所以應該要了解，這些事情可以幫助你在遇到新專案、新需求或團隊中出現瓶頸時，如何有效運用現有資源解決問題。
對於新需求或改善，開發速度和品質往往取決於對現有架構的理解。今天可能有一個新需求是上傳圖片並生成縮略圖，假設在某個功能中已經有類似模組，只需要對現有功能做修改即可，但如果 Tech Lead 不了解這一點，可能會導致花費更多時間和資源。
團隊也會經常與 Tech Lead 討論各種技術決策或特定需求的實現，上述提到的事情都是幫助你提出意見的好素材。只有真正深入了解架構，了解開發人員所遇到的困難，澄清彼此的需求，才不會讓新需求或解決方案變得空中樓閣。
後記
在一年前的「成為 Tech Lead 的一些感想」一文中，我發現自己已經不太在意是否加薪（但還是會在意），一方面是因為對現在的職位和工作模式與內容都相當滿意，另一方面是體會到每個人都有自己的工作方式，只要把自己的本分做好就無愧於心。
雖然私下可能還是會在推特上抱怨幾句，但我仍然會盡可能提高團隊的生產力，持續改善現有的開發流程和專案。