: 有個功能A、B都會用到相同邏輯，且有兩份重覆的code
: (沒有unit test保護，而且年久失修 要加入unit test會需要更多時程)
: 現在要加入C，也會用到相同邏輯
: 身為合格的工程師 應該會把ABC重覆的部份提取出來
: 而不是讓這邏輯重覆三次
: 但以公司營運的角度來看 這次專案就只會測試C的部份
: 不應該動到A、B
: 這時就要冒著A、B壞掉風險重構，或是因為來不及加入unit test
: 就乾脆讓相同邏輯存在三個地方
: 身為專業工程師，我很想選擇重構
: 但過去的經驗告訴我
: 絕對要以kpi為最優先考量
: 於是程式充滿了註解、重覆片段
: 雖然靠著筆記、git log，能還原當時寫code的思路
: 但這些髒code就會永遠留存在程式裡
: 想問大家遇到這情況會怎麼做?
如果 A, B 都沒有任何 tests，建議不要動他。
幫 C 實做這個功能的時候，把 unit test 寫好寫滿，確保 C 是對的
行有餘力，針對 A, B 的使用情境也加上 test case，確保未來在 A, B 確實能重用
(這點很重要，否則很容易程式長得很像你以為可以重用，實際上根本不能)
就先做到這樣就好，確保 C 的品質，同時你獲得了高品質的 reusable 模組
隨著時間推演，有幾種情況:
1. A, B 的生命週期已經結束，直接淘汰，不用 refactor (這超常發生)
2. A, B 只是在維護修 bug，不會再有新功能，那通常也不值得花時間去弄
但若經常造成 bugs 的地方，正是跟 C 共用的那段程式，
那 refactor 就很有商業價值，長官也不會反對你做。
這種時候 refactor A, B 會變成重要的工作，你就不會沒時間做。
Refactor 完畢之後改善多少，就可以變成 Kpi，做起來名正言順
3. 如果真的發展到有機會 refactor A, B，這時就先幫最主要商業邏輯加上
"大範圍" 的 "integration tests" (不用花時間補寫 A, B 的 unit tests)
接著把 A, B 重複的邏輯抽換成 C 的 (之前開發 C 已 unit test 過，確保正確)
抽換完畢後，大範圍整合測試確認整體行為沒改變，就可以收工了
上線後持續監測，萬一遇到問題，直接 rollback 回上一版
專業的工程師，在開發的時候也會考慮實務面，以及這些 code 的商業價值，
來決定事情的先後順序，幫助產品獲得成功。
好的外科醫師，手術開刀，目標是病人要治好，而不是手術成功，病人死亡。
--
Sent from PCMan on PCMan's PC
--