Re: [討論] 重構跟kpi的考量

看板Soft_Job作者HZYSoft (PCMan)時間2年前 (2022/02/26 23:43)推噓19(19推 0噓 2→)

留言21則, 21人參與討論串3/4 (看更多)

※ 引述《VScode (VSisBestIDEinTheWorld)》之銘言： : 假設以下情境 : 有個功能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 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 111.249.169.220 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1645890217.A.B0F.html ※ 編輯: HZYSoft (111.249.169.220 臺灣), 02/26/2022 23:46:42

推

accessdenied

02/27 00:26, 2年前 , 1^F

02/27 00:26, 1^F

推

GLaDOS1105

02/27 00:57, 2年前 , 2^F

02/27 00:57, 2^F

推

Raymond0710

02/27 01:01, 2年前 , 3^F

02/27 01:01, 3^F