作者leo5916267 (封膜獵人)
看板Soft_Job
標題Re: [討論] 重構跟kpi的考量
時間Sun Feb 27 00:32:59 2022
※ 引述《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://webptt.com/m.aspx?n=bbs/Soft_Job/M.1645893181.A.443.html
1F：→ Gaitz: 這麼說來你們會在所謂的需求穩定後，停下來大規模的重寫重 02/27 01:10
2F：→ Gaitz: 構改好架構？還是最後根本沒有時間而且又要開發新需求，然 02/27 01:10
3F：→ Gaitz: 後說需求沒有穩定？永遠沒有做好？ 02/27 01:10
4F：→ Gaitz: 有新需求會被共用的地方卡住這件事聽起來很奇怪，覺得單一 02/27 01:14
5F：→ Gaitz: 責任原則沒有做好。 02/27 01:14
6F：噓 accessdenied: 不贊成。初期就這樣做，只會遺留一大堆90%相似只有1 02/27 01:16
7F：→ accessdenied: 0%客製的程式碼，然後未來修改，只敢全文搜索 find 02/27 01:16
8F：→ accessdenied: replace 02/27 01:16
9F：→ accessdenied: 而且，一旦分開管理，我保證沒人有勇氣統整回來 02/27 01:17
10F：推 xenorock: 我看法同樓上，沒有先Design好，分割完全，全部搞在一起 02/27 01:27
11F：→ xenorock: 後面有的痛苦 02/27 01:27
12F：→ t64141: 初期到處貼你要有把握後期能整理，不然後面維護的人就會 02/27 01:33
13F：→ t64141: 變下一個原原po，很容易惡性循環的 02/27 01:33
14F：→ t64141: 至於被共用卡住的問題，遇到特例難以擴充再另外實作就好 02/27 01:37
15F：→ t64141: ，維護時因為特例而重複比初期就到處貼的副作用小多了 02/27 01:37
16F：推 MyNion: 我覺得你會被卡住，就代表一開始方法＆功能就沒拆好了 02/27 02:23
17F：推 MyNion: 將程式模組化，增添彈性的接口供外部呼叫 02/27 02:25
18F：→ MyNion: 如果這樣還不行，那就代表從一開始這兩者就毫無相同之處 02/27 02:29
19F：→ MyNion: 本來就要分開寫了 02/27 02:29
20F：→ TakiDog: 程式碼要增加很容易，要減少太難，那為何一開始不規劃好 02/27 02:39
21F：→ labbat: 本來只要做加法函數，結果做成通用算數函數 02/27 03:06
22F：→ labbat: 不如一開始就設計通用算數函數 改壞了也只是大家一起壞掉 02/27 03:09
23F：推 geroge0820: 推文完全文不對題... 重點是需求還不穩定這件事吧 02/27 03:14
24F：推 wulouise: 可以共用的code怎麼可能會大到需求改變就一堆特例 02/27 09:40
25F：→ wulouise: 通常都是srp沒處理好才在怕改A錯B 02/27 09:41
26F：噓 handsomeLin: 如果會有發現重複code然後還複製貼上的話就是design 02/27 11:28
27F：→ handsomeLin: 不行 02/27 11:28
28F：噓 kkes0001: 絕對不要這樣做 02/27 11:48
29F：→ foreverk: 會被共用程式碼卡住，就代表沒抽乾淨，應該要去釐清邏 02/27 13:42
30F：→ foreverk: 輯，而不是跑去貼一堆重複code然後事後才要處理吧，本 02/27 13:42
31F：→ foreverk: 末倒置 02/27 13:42
32F：→ foreverk: 會覺得要花大量時間測試，就代表一開始你就沒有寫好uni 02/27 13:44
33F：→ foreverk: t test 02/27 13:44
34F：→ srwhite: 反了吧應該先寫一起等真的有不同要複製再複製啊 02/27 13:50
35F：→ t64141: 需求不穩定不是重點，一開始到處複製，需求變化過程要改 02/27 14:46
36F：→ t64141: 就已經需要到處翻找了，即使等需求確定後也是要面臨重構 02/27 14:46
37F：→ t64141: 的問題，萬一屆時已經上線更悲劇 02/27 14:46
38F：→ neo5277: 這篇是用接案公司的想法出發寫MVP的時候吧? 02/27 15:17
39F：推 viper9709: 對系統還不夠了解時,這才是比較實用的+1 02/28 00:08
40F：推 Nonsense8: 樓主沒說錯，這適用於未上線的專案，如果老闆在開發中 02/28 10:19
41F：→ Nonsense8: 要求大改，主管有責任爭取上線後重構時間。甚至需求大 02/28 10:19
42F：→ Nonsense8: 改也不是老闆的責任，尤其市場上沒有其他競品可以參考 02/28 10:19
43F：→ Nonsense8: 時，才會不時在開發中更改需求 02/28 10:19
44F：→ Nonsense8: 但原文的情境應該是上線後營運很久的專案，就不適合這 02/28 10:21
45F：→ Nonsense8: 種作法了 02/28 10:21