Google 的軟體工程之道 (17) — 棄用 ( Deprecation)

https://innovecs.com/blog/building-software-development-teams/

此系列為 【 Google 的軟體工程之道 】一書的書摘與點評，期待用最精要的文字，帶來豐富的內容分享。預計 2~3 周左右會有一篇更新，歡迎追蹤支持!

【 Google 的軟體工程之道 】全系列: https://medium.com/@johnliutw/list/da301cc31b15

為什麼要棄用?

1. 基本前提: 程式碼是負債，而不是資產，有價值的是其功能的部分。在維護的部分，需要保持營運資源並且和周圍生態系一起更迭
2. 對於過時且有類似替代品的系統，棄用是個適合的決策

為什麼棄用很難?

1. 基於 Hyrum’s 定律，使用者時常以意外或不可預見的方式使用系統，尤其是使用者越多且越古老的系統
2. 新系統不一定和舊系統功能性完全一致，切換的效益需要謹慎評估
3. 原作者的情感依戀，移除工程師的作品，會有情緒性的問題需要克服
4. 老舊系統的成本難以估算，但棄用的高昂成本卻易於觀察

如何棄用?

1. 設計系統時，即為到時要做出棄用來做準備，並影響設計方式
2. 思考使用者遷移至其他解決方案的難易程度以及如何拆解為更小部分處理
3. 思考組織是否會長期支持這個專案

棄用的方式

1. 建議性棄用，比較軟性，提供替代方案，但沒有支援遷移的計畫。適合在新方案對於使用者有巨大的利益時，讓使用者有誘因自行處理遷移的問題。
2. 強制性棄用，通常伴隨系統移除的最後期限，並有專門團隊協助使用者做系統的遷移，尤其可能對於使用者團隊並無資源能執行此任務的情境時。對於不知道對於舊系統依賴的團隊，可以執行一些如 API contract 修改的小漏洞，來幫助該團隊發現其依賴，並能針對真正的棄用日做準備。
3. 警告性棄用，通常需要具備可操作與相關性，讓使用者能執行一些相關動作，並且要避免過多警告造成的 alert fatigue ( 警覺疲勞 )。警告須在程式碼編寫完成時即跳出，而不是在合併入主幹的數天後。

管理棄用流程

1. 棄用的流程需要有專屬的 owner，集中性的執行棄用工作，並試著讓這項工作在對應的使用者團隊中，能使用 20% 的重要但不緊急工作時間做處理
2. 明確的里程碑，並且能夠分隔成不同部分，而不只是遷移完成 這一種。
3. 找出能幫助效率的工具，主要應聚焦在發現對於欲棄用專案的使用者和大規模遷移工具。尋找使用的方式可以透過靜態程式碼分析，找出內部依賴 ; 也能透過 log 紀錄，定位外部或動態依賴。大規模遷移的作法，會在下一章節做介紹。
4. 需要避免有團隊又使用了已棄用的專案

如果喜歡這個系列的話，歡迎將此連結加入你的最愛:

【 Google 的軟體工程之道 】全系列 https://medium.com/@johnliutw/list/da301cc31b15