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

看板Soft_Job作者 (封膜獵人)時間2年前 (2022/02/27 00:33), 編輯推噓4(7推 3噓 35→)
留言45則, 16人參與, 2年前最新討論串4/4 (看更多)
※ 引述《VScode (VSisBestIDEinTheWorld)》之銘言： : 假設以下情境 : 有個功能A、B都會用到相同邏輯，且有兩份重覆的code : (沒有unit test保護，而且年久失修 要加入unit test會需要更多時程) : 現在要加入C，也會用到相同邏輯 : 身為合格的工程師 應該會把ABC重覆的部份提取出來 : 而不是讓這邏輯重覆三次 : 但以公司營運的角度來看 這次專案就只會測試C的部份 : 不應該動到A、B : 這時就要冒著A、B壞掉風險重構，或是因為來不及加入unit test : 就乾脆讓相同邏輯存在三個地方 : 身為專業工程師，我很想選擇重構 : 但過去的經驗告訴我 : 絕對要以kpi為最優先考量 : 於是程式充滿了註解、重覆片段 : 雖然靠著筆記、git log，能還原當時寫code的思路 : 但這些髒code就會永遠留存在程式裡 : 想問大家遇到這情況會怎麼做? 我覺得有個盲點就是 重複程式碼的邏輯 我的經驗是在需求還沒穩定前 一樣的程式碼複製到不同地方才是最佳解 你根本不知道什麼時候 某個地方要用的邏輯不同 一但要改寫的邏輯不通 你就會被共用的程式碼卡住 就如你提到的案例 你只能砍掉重寫 不然你就要很痛苦的把問題解決這時你就會寫出 共用的難以維護的程式碼 ，這反而比重複程式碼還糟糕，看了很痛苦要改還要花大量時間 測試哪邊會壞掉 另一種方式就是 C 不要共用的程式碼 獨立寫一份 之後找時間把 共用程式碼放回AB 你這樣反而會乾淨很多 通常能拆出去的程式碼是無屬性的 不然只是目前剛好有一樣的邏輯 而不是可以共用的程式碼 -- Sent from nPTT on my iPhone SE (2 Gen) -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 36.233.146.252 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1645893181.A.443.html
→
02/27 01:10, 2年前 , 1F
這麼說來你們會在所謂的需求穩定後，停下來大規模的重寫重
02/27 01:10, 1F
→
02/27 01:10, 2年前 , 2F
構改好架構？還是最後根本沒有時間而且又要開發新需求，然
02/27 01:10, 2F
→
02/27 01:10, 2年前 , 3F
後說需求沒有穩定？永遠沒有做好？
02/27 01:10, 3F
→
02/27 01:14, 2年前 , 4F
有新需求會被共用的地方卡住這件事聽起來很奇怪，覺得單一
02/27 01:14, 4F
→
02/27 01:14, 2年前 , 5F
責任原則沒有做好。
02/27 01:14, 5F
噓
02/27 01:16, 2年前 , 6F
不贊成。初期就這樣做，只會遺留一大堆90%相似只有1
02/27 01:16, 6F
→
02/27 01:16, 2年前 , 7F
0%客製的程式碼，然後未來修改，只敢全文搜索 find
02/27 01:16, 7F
→
02/27 01:16, 2年前 , 8F
replace
02/27 01:16, 8F
→
02/27 01:17, 2年前 , 9F
而且，一旦分開管理，我保證沒人有勇氣統整回來
02/27 01:17, 9F
推
02/27 01:27, 2年前 , 10F
我看法同樓上，沒有先Design好，分割完全，全部搞在一起
02/27 01:27, 10F
→
02/27 01:27, 2年前 , 11F
後面有的痛苦
02/27 01:27, 11F
→
02/27 01:33, 2年前 , 12F
初期到處貼你要有把握後期能整理，不然後面維護的人就會
02/27 01:33, 12F
→
02/27 01:33, 2年前 , 13F
變下一個原原po，很容易惡性循環的
02/27 01:33, 13F
→
02/27 01:37, 2年前 , 14F
至於被共用卡住的問題，遇到特例難以擴充再另外實作就好
02/27 01:37, 14F
→
02/27 01:37, 2年前 , 15F
，維護時因為特例而重複比初期就到處貼的副作用小多了
02/27 01:37, 15F
推
02/27 02:23, 2年前 , 16F
我覺得你會被卡住，就代表一開始方法＆功能就沒拆好了
02/27 02:23, 16F
推
02/27 02:25, 2年前 , 17F
將程式模組化，增添彈性的接口供外部呼叫
02/27 02:25, 17F
→
02/27 02:29, 2年前 , 18F
如果這樣還不行，那就代表從一開始這兩者就毫無相同之處
02/27 02:29, 18F
→
02/27 02:29, 2年前 , 19F
本來就要分開寫了
02/27 02:29, 19F
→
02/27 02:39, 2年前 , 20F
程式碼要增加很容易，要減少太難，那為何一開始不規劃好
02/27 02:39, 20F
→
02/27 03:06, 2年前 , 21F
本來只要做加法函數，結果做成通用算數函數
02/27 03:06, 21F
→
02/27 03:09, 2年前 , 22F
不如一開始就設計通用算數函數 改壞了也只是大家一起壞掉
02/27 03:09, 22F
推
02/27 03:14, 2年前 , 23F
推文完全文不對題... 重點是需求還不穩定這件事吧
02/27 03:14, 23F
推
02/27 09:40, 2年前 , 24F
可以共用的code怎麼可能會大到需求改變就一堆特例
02/27 09:40, 24F
→
02/27 09:41, 2年前 , 25F
通常都是srp沒處理好才在怕改A錯B
02/27 09:41, 25F
噓
02/27 11:28, 2年前 , 26F
如果會有發現重複code然後還複製貼上的話就是design
02/27 11:28, 26F
→
02/27 11:28, 2年前 , 27F
不行
02/27 11:28, 27F
噓
02/27 11:48, 2年前 , 28F
絕對不要這樣做
02/27 11:48, 28F
→
02/27 13:42, 2年前 , 29F
會被共用程式碼卡住，就代表沒抽乾淨，應該要去釐清邏
02/27 13:42, 29F
→
02/27 13:42, 2年前 , 30F
輯，而不是跑去貼一堆重複code然後事後才要處理吧，本
02/27 13:42, 30F
→
02/27 13:42, 2年前 , 31F
末倒置
02/27 13:42, 31F
→
02/27 13:44, 2年前 , 32F
會覺得要花大量時間測試，就代表一開始你就沒有寫好uni
02/27 13:44, 32F
→
02/27 13:44, 2年前 , 33F
t test
02/27 13:44, 33F
→
02/27 13:50, 2年前 , 34F
反了吧應該先寫一起等真的有不同要複製再複製啊
02/27 13:50, 34F
→
02/27 14:46, 2年前 , 35F
需求不穩定不是重點，一開始到處複製，需求變化過程要改
02/27 14:46, 35F
→
02/27 14:46, 2年前 , 36F
就已經需要到處翻找了，即使等需求確定後也是要面臨重構
02/27 14:46, 36F
→
02/27 14:46, 2年前 , 37F
的問題，萬一屆時已經上線更悲劇
02/27 14:46, 37F
→
02/27 15:17, 2年前 , 38F
這篇是用接案公司的想法出發寫MVP的時候吧?
02/27 15:17, 38F
推
02/28 00:08, 2年前 , 39F
對系統還不夠了解時,這才是比較實用的+1
02/28 00:08, 39F
推
02/28 10:19, 2年前 , 40F
樓主沒說錯，這適用於未上線的專案，如果老闆在開發中
02/28 10:19, 40F
→
02/28 10:19, 2年前 , 41F
要求大改，主管有責任爭取上線後重構時間。甚至需求大
02/28 10:19, 41F
→
02/28 10:19, 2年前 , 42F
改也不是老闆的責任，尤其市場上沒有其他競品可以參考
02/28 10:19, 42F
→
02/28 10:19, 2年前 , 43F
時，才會不時在開發中更改需求
02/28 10:19, 43F
→
02/28 10:21, 2年前 , 44F
但原文的情境應該是上線後營運很久的專案，就不適合這
02/28 10:21, 44F
→
02/28 10:21, 2年前 , 45F
種作法了
02/28 10:21, 45F
‣ 更多 leo5916267 的文章
文章代碼(AID): #1Y6bOzH3 (Soft_Job)
‣ 更多 leo5916267 的文章
文章代碼(AID): #1Y6bOzH3 (Soft_Job)