0%

弱雞 Tech Lead 初體驗

近期很後悔自己中斷了寫部落格的習慣,為了重新養成這個習慣,所以有了這開春第一篇文章(都快夏天了老闆~),而既然是開春第一篇,想說就來寫些較軟性的題目好了(絕對不是我技術都沒長進的關係啦…),所以今天就來聊聊近期與團隊共患難的事情好了。

可能老闆知道我今年犯太歲的關係,不能讓我太好過,所以年初就派我去擔任一個 5 人小團隊的 tech lead,一開始本來懷抱著 “大家都很優秀,我應該只要去幫大家打打雜就好”的心態加入,殊不知考驗才剛剛開始。

這個團隊負責的是一個架構與開發框架性質的專案,亦即它的設計未來可能會直接影響 N 個團隊的開發習慣與 N 個服務掛在上面的行為,所以它的難度不低,加上初期時程壓力、人力吃緊的情況下,體質並不是很好,例如:

  • 專案幾乎沒有測試,上線常常發生改 A 壞 B 的情況
  • 文件非常多,但跟實際系統運作邏輯有不小的落差
  • 系統在還不穩固的情況下已經釋出 SDK 給團隊使用,加大改版向下相容的挑戰
  • Release 純手工,過程中需要人工介入調整許多地方,不熟的人看文件還要花半天以上才能搞定
  • 框架本身的目標與使用該框架的服務需求間的拉扯,導致初期就有高度客製化的狀況,增加了後續入住這個框架得複雜度
  • 資料庫版控管理不佳,每次更版幾乎都要倒資料,間接也讓服務開不出 API,因為實時的資料異動會導致資料遺失

基於上述原因,團隊士氣其實並不高,因為即便是看似簡單的功能上線都如履薄冰,加上該專案是受到重視的專案(被定位為乘載公司未來性的框架),人員陸續補進來,團隊的壓力也隨之增加,因為人力往往與產值掛鉤,給予對應的人力沒有對應的產值是無法被接受的。

所以初期我花最多時間思考的不是怎麼滿足需求,反而是該如何穩住系統跟增加開發成員的信心,在軟體業也快 10 年了,新需求與改需求是不會有停止的一天,每個跟你談的需求都會很急很趕,不急不趕才是新聞,所以與其追著需求跑,我更在思考的是

  1. 該如何穩住這個系統 ? 讓開發人員有信心,讓新進人員能在最短時間成為戰力
  2. 這個框架到底想解決的本質問題是什麼? 如果它沒有守住那條線,這個框架基本上也沒有存在的價值

所以我跟主管談了一個方案,農曆年前約三週時間需求我一律不收也不處理,一切請他幫我緩到農曆年後再說,對內開始跟團隊成員著手處理以下問題

  1. 重建系統核心
    我開始與團隊成員梳理目前系統運作的脈絡,對我來說系統要在不斷變動的環境下發展,不外乎讓你的程式碼能好好說明系統在做什麼,如果連幾個類別物件間的互動關係都說不清楚寫不好,又該如何期待這成千上萬行的程式碼堆疊出來系統會有一套清晰的邏輯在運作。又如何期待新進工程師能在眾多的文件中自己理出系統邏輯,縱然文件全然正確,理解文件後對應到程式碼的運作,這中間還有一段很長的路要走。所以我很喜歡 Uncle Bob 說的『世界上最好的文件應該是你的程式碼。』
    這個觀念剛好也契合 DDD 中所強調的,把你的專注力先放在解決核心問題上,把問題之外的資料庫、 Schema、 軟體分層、作業系統先切開,先用最簡單的類別與物件來展示你要解決的業務邏輯,當這些都說得通、運作得當,剩下的都是支撐這個核心的基礎建設而已。
  1. 建立單元測試
    我與團隊成員立下的第一個約定就是 “MR 只要沒有單元測試一律退回”,我認為確保寫出來的程式運作邏輯的正確性是身為工程師的基本素養,Code Review 應該是讓大家討論與互相學習的場域,並試著透過多人 Review 從不同角度尋找盲點,防止重大舞弊、效能、資安…等問題,不要期待 Reviewer 能用肉眼幫你找出所有漏洞,如果寫單元測試都無法保證系統百分之百正確了,更何況不寫。
    寫單元測試好處真的很多,除了能用最低成本快速驗證你的想法與程式碼之外,它也在保護你的團隊成員,當專案龐大到一個程度,團隊內成員對於 Code 與各個需求掌握度也都會有落差,所以當未來需求變動時,它能幫忙把關是否哪邊因為變動而出錯了。
  1. 重新梳理開發流程與 CI/CD
    與團隊成員討論了之前的分支策略後利弊後,我們開始改成 trunk-based 的跑法,試著降低大家解衝突的時間,並逼大家思考持續整合回 Master 的相容性問題,同時也開始投入資源建立 CI/CD ,讓一些明確與重複的流程自動化,降低部署的時間與負擔。穩固快速的部署流程不單單只是減少時間的浪費,往往也能增加團隊成員的信心,你會有信心即便真的最後出錯了,我們都有機會在很短的時間內迭代修復或退版,就像打籃球時有個超強中鋒幫你搶籃板一樣,各個投三分都跟 Curry 一樣有信心 (最近都在看 NBA 季後賽啦)。

經過一番奮戰後,我們終於在總共花了 4 週多的時間,將原本幾乎開不出 API 的系統,陸續釋出 20多支的 API 上線,並且交付批次工具幫助協作單位整合資料,解決了之前常常需要手動進資料庫塞資料與髒資料橫行的問題,也終於終於得到了團隊成員的第一次肯定(淚)。

但人生往往不會這麼簡單,你懂的 …

待續 …