我們如何面對技術債
近期團隊內加入不少新血，他們都是擁有許多經驗的工程師。剛好藉由這個機會來看看在剛接觸這份 code base 的新人們的眼中，有什麼看不懂的地方，亦或是覺得有哪些部分的設計有問題，由不同的角度提出不一樣的觀點。
就目前為止我們有討論出幾個較嚴重的問題：
- 架構已不符目前 feature 實作的需求
- 舊有架構的實作在經過疊床架屋之下顯得髒亂不堪
- 需要引用新的語言、新的設計模式改善產品效能
當然我們明白公司還在 Startup 階段，產品仍然需要快速的迭代，而大多數的團隊在資源不足的情況底下會選擇打安全牌。但對我們來說這正是提升我們團隊實力的絕佳時刻！
出來面對
當面對這樣龐大的技術債時，第一個要評估的當然是對於團隊的影響力。 在 Ash Wu 的 技術債不還會怎麼樣？如何評估技術債 這篇文章中有提到評估技術債的方式，也就不再贅述。
不過評估過後該怎麼動手，該怎麼在團隊當中凝聚共識，設定計畫以及目標才是容易被忽略的一環！
步驟
要面對這些技術債並不容易，除了需要熟悉完整的商業邏輯、熟悉該程式語言之外，如果涉及到整個 project 的架構，更是一個困難的問題。
所幸，我們可以利用 分析、評估、記錄、行動，讓整件事情變得有邏輯、可分類、可判斷進而發展到可處理。
分析
首先我們把整個專案當中有問題的結構找出來，這個部分其實很花人力時間。必須要由足夠經驗以及熟悉架構的人來分析存在專案當中的壞味道。
這部份我們可以從幾個層面著手：
- View hierarchy (View controller architecture design)
- API call design
- Relationship between `view` and `data`
- Utilities (Category, Tools, Helper and so on)
- Testability
列舉所有問題/疑問，並且追問當初設計的原意才能得知當初的設計是不是符合現在的情境。
評估
評估最主要是區分哪些部分需要先被處理，而決定優先權的因素大致上有幾項：
- 對於產品效能的嚴重性
- 解決技術債的人力成本、時間成本
- 解決技術債的方法、方向。也就是採取什麼樣的方式來修正技術債
- 如何影響未來產品開發（壞code的擴散性、影響開發的困難度）
根據這些指標將問題記錄下來，以便未來將其依照優先權高低來規劃到團隊的 fundamental road map 之中。
紀錄
所有的問題不可能一次解決，所以我們必須先記錄它們以免未來過度重複分析我們的專案，造成時間上的浪費。
這樣的紀錄後續可以用在兩個方向
1. 規劃團隊專案 fundamental road map
2. 將技術 task 納入未來產品規劃的考量
第一點大部分的團隊應該都可以想得出來、也都做得到，但值得一提的是要將問題分類，並將特別重要的項目標示出來。
第二點就相對比較困難了，它必須仰賴整個開發團隊(這邊指包含 PM 、技術主管、QA 等等的全部)彼此的默契及信任。
如果只是跟 PM 要時間說我要還技術債，這樣有點口說無憑。所以有完整的文件規劃及記錄會有助於彼此溝通，而其內容必須詳細說明這些問題對產品會有什麼影響，我們打算用什麼樣的方式改善用戶體驗，亦或是改善 RD 開發體驗等等的目標，及各項目標需要使用到的資源及時間，並且說明其未來可能造成的負面影響。而我想這份文件會體現團隊負責任的態度，能它用來作為後續溝通、討論、追蹤的一個工具，也是爭取時間及建立信任的一個最佳的籌碼。
行動
當然評估得再多、記錄得再多，如果沒有行動一切也只是空談。 這些行動不單單是落在資深開發者的身上，也不該只是團隊當中某一些人的責任，這應該是團隊當中每一個人都應該共同承擔的任務。
