作者VScode (VSisBestIDEinTheWorld)
看板Soft_Job
標題[討論] 重構跟kpi的考量
時間Thu Feb 24 01:13:40 2022
假設以下情境
有個功能A、B都會用到相同邏輯，且有兩份重覆的code
(沒有unit test保護，而且年久失修 要加入unit test會需要更多時程)
現在要加入C，也會用到相同邏輯
身為合格的工程師 應該會把ABC重覆的部份提取出來
而不是讓這邏輯重覆三次
但以公司營運的角度來看 這次專案就只會測試C的部份
不應該動到A、B
這時就要冒著A、B壞掉風險重構，或是因為來不及加入unit test
就乾脆讓相同邏輯存在三個地方
身為專業工程師，我很想選擇重構
但過去的經驗告訴我
絕對要以kpi為最優先考量
於是程式充滿了註解、重覆片段
雖然靠著筆記、git log，能還原當時寫code的思路
但這些髒code就會永遠留存在程式裡
想問大家遇到這情況會怎麼做?
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 115.43.126.106 (臺灣)
※ 文章網址: https://webptt.com/m.aspx?n=bbs/Soft_Job/M.1645636422.A.77F.html
※ 編輯: VScode (115.43.126.106 臺灣), 02/24/2022 01:14:25
1F：→ labbat: 一堆重複程式碼以及註解，真的好髒 02/24 01:17
2F：推 acgotaku: 要我一定改,既然改就不要單純抽離,用clean code層面思考 02/24 01:21
3F：推 devilkool: 為了預防DEFG也用到一樣的東西，至少這次寫乾淨點 02/24 01:23
4F：→ acgotaku: 會這樣就代表中間業務邏輯更動了,無法遵循open-closed 02/24 01:24
對 看似重覆 卻有一點地方不太一樣
5F：推 f496328mm: 考績只是一時的，繼續寫爛 code，對職涯發展不好，長期 02/24 01:32
6F：→ f496328mm: 來看就是自廢武功 02/24 01:32
我也是這樣想 不想為了kpi昧著良心
7F：→ yyc1217: 看你的份量 跟要不要對三個月後的自己好一點 02/24 01:44
這倒是還好 這個地方的code好幾年沒動了
8F：推 wadechen: If it ain’t brake , don’t fix it 02/24 01:46
9F：→ yyc1217: 至少C要寫的話一定會加上unit test 02/24 01:46
10F：→ wadechen: 先把C邏輯的泛用性處理好 之後讓A,B可以簡單引用又方便 02/24 01:47
11F：→ wadechen: 測試 02/24 01:47
12F：推 wadechen: 大家寫久了多少會有潔癖 但出來工作有時候要克制這種潔 02/24 01:51
13F：→ wadechen: 癖 尤其負責的專案越大 協同作戰的人又多時 重構的成本 02/24 01:51
14F：→ wadechen: 可能超乎想像 02/24 01:51
是啊 功能複雜的地方要重構 要有很完整的測試
15F：推 wadechen: 我是覺得未來自己寫的扣 盡量保持乾淨易擴充易讀即可 02/24 01:53
16F：推 neo5277: 有錢嗎？有就切沒有就算了老闆不會在意 02/24 01:55
17F：→ angusyu: 沒時間就到沒看到，又不是你的問題。有時間也要看公司文 02/24 01:58
18F：→ angusyu: 化跟趴數夠不夠，改了很容易產生副作用，還要不怕被幹譙 02/24 01:58
19F：噓 MoonCode: 重複跟髒有什麼關係？ 02/24 02:01
20F：→ asadman1523: 先看看A、B壞掉你能負責嗎... 02/24 02:12
kpi會很慘...
21F：推 MoonCode: 02/24 02:20
22F：推 CoNsTaR: 先讓 C 再重複一次，等確認 C 沒問題了再來討論要怎麼重 02/24 03:13
23F：→ CoNsTaR: 構啊 02/24 03:13
24F：推 ctrlbreak: 政治問題 如果出事情你能不能負責 02/24 03:58
25F：推 airtsubasa: 寫的乾淨沒人感激你 前人挖洞 你也一起玩啊 反正專案 02/24 05:40
26F：→ airtsubasa: 也是會輪流的 顆顆 02/24 05:40
27F：噓 peter98: 工程師搞KPI? 哪間公司啦 說來笑笑 02/24 05:49
28F：推 CoNsTaR: 樓上，Amazon 和 Facebook 平時都是你嘲笑的對象嗎？ 02/24 05:55
29F：→ james732: 如果有足夠的時間與把握讓A B C都正常再說吧 02/24 06:07
30F：→ james732: 原本好好的改壞這個問題有時會非常嚴重 02/24 06:08
31F：→ james732: 我應該會新增C但預留了日後整合A/B的彈性 02/24 06:09
32F：→ james732: 或者一口氣改好但先驗證C是OK的再把AB切換過去 02/24 06:10
33F：→ james732: 如果時間不夠的話就不要碰AB了把C做好驗好就好 02/24 06:13
嗯嗯 我覺得我應該會這樣做
等未來要改A B時，再重構A B
34F：噓 peter98: C大很懂?在哪高就? 02/24 06:16
35F：推 RINPE: 看薪水吧 薪水到位 一切好談 02/24 06:43
36F：推 Solinarymoon: 先把重複邏輯的地方獨立出來給C用並預備給A、B用， 02/24 07:13
37F：→ Solinarymoon: 後續有動到A、B的時候再修改？ 02/24 07:13
目前會這樣做
38F：推 del680202: 會問這種問題 就是你的不專業了 02/24 07:39
要如何兼顧專業跟績效呢?
※ 編輯: VScode (115.43.126.106 臺灣), 02/24/2022 08:45:52
39F：→ ericthree: 歷史包袱啊 02/24 08:42
40F：→ foreverk: 過去遇到這情況，我先把共用抽出來給C使用，後面有空再 02/24 08:43
41F：→ foreverk: 陸續套上A和B以及各自的unit test，這個邏輯可以套用所 02/24 08:43
42F：→ foreverk: 有你想重構的場景，視情況變化一下而已 02/24 08:43
43F：→ ericthree: 如果團隊不想解決 就大家一起放著爛 02/24 08:43
44F：→ foreverk: 多做這件事不一定有錢啦，但是熟練以後時間成本會越來 02/24 08:45
45F：→ foreverk: 越低，久了你就不會再把KPI和clean code放在天秤上衡量 02/24 08:45
46F：→ foreverk: 半天 02/24 08:45
只是這地方可能好幾年才動一次
會有一股衝動想一口氣弄好
※ 編輯: VScode (115.43.126.106 臺灣), 02/24/2022 08:48:18
47F：→ foreverk: 這個風險跟相信我能反殺差不多高，最好別吧 02/24 08:53
48F：→ bheegrl: 你可以考慮做C的時候先把和A、B重複的邏輯各別提出來 02/24 09:20
49F：→ bheegrl: 也就寫成C + A~C共用邏輯(假定是兩隻method) 02/24 09:21
50F：→ bheegrl: 你實際上只用寫了C，等以後有人要改A、B時再順便重構就好 02/24 09:22
51F：→ bheegrl: 這樣你概做出彈性來又不用一次性擔太多風險 02/24 09:23
52F：→ bheegrl: *既 02/24 09:27
53F：推 LeoSW: 想想看怎麼把重構變成KPI啊 02/24 09:30
54F：推 t64141: 共用部分抽吃來，只有C套用，接著開單做AB重構 02/24 09:39
55F：→ t64141: *抽出來 02/24 09:39
56F：→ ssccg: 你可以把C寫成以後DEFG可以用，但先別動AB 02/24 09:56
57F：→ ssccg: 以後真要改AB時也能引用C，是說很可能以後改AB又另一個故事 02/24 09:57
改AB 可能是幾年後別人改
這時要把註解寫很清楚
哪裡重覆 哪裡要移去哪裡
我覺得也滿麻煩的
※ 編輯: VScode (203.67.131.41 臺灣), 02/24/2022 10:18:51
58F：→ l8th: 為什麼在這裡跟局外人糾結？go talk to your mgr and call a 02/24 10:49
59F：→ l8th: design session. present pros and cons to your team. thi 02/24 10:49
60F：→ l8th: s is a team decision, not yours. 02/24 10:49
61F：推 LIN810116: 有版本跟分支控制不用怕改壞啊 02/24 11:23
62F：推 CoNsTaR: @peter98 敝司某 fortune 20，沒有 kpi 不用為我擔心 02/24 12:00
63F：→ knives: 現在沒有壞的東西，不要沒事找事做，有空看ptt不好嗎 02/24 14:52
64F：→ lazarus1121: 我之前是用類似藍綠部屬，用一個if控制新舊版本 02/24 15:39
65F：→ lazarus1121: 然後用設定檔控制切換，如果發現有錯就立刻切回舊版 02/24 15:40
66F：推 sniper2824: 理論上是跟你同事討論才對 02/24 16:06
67F：→ sniper2824: 但你重構的夠好 注解就不用寫得像之前那樣了不是嗎？ 02/24 16:07
重構當然就不用註解了
問題是會冒著其他功能壞掉的風險
68F：推 asleisureto: 等C穩定後再逐漸把AB功能加進去，這期間還是繼續用A 02/24 16:10
69F：→ asleisureto: B，穩點來不要一口氣直接改AB 02/24 16:10
70F：→ asleisureto: 重構很多時候看你年資跟老闆主管挺不挺就是 02/24 16:12
是啊 以更上層的想法 一定是不要壞掉就好了
71F：推 somefatguy: A B不動但rename加上deprecated，並加註解說明請改用 02/24 16:19
72F：→ somefatguy: 重構過的A’ B’。然後抽出共用模組給A’ B’ C用。這 02/24 16:19
73F：→ somefatguy: 樣以後的人也知道新功能不要再呼叫舊的A B改用A’ B’ 02/24 16:20
74F：→ somefatguy: 。 02/24 16:20
這個方法不錯 都忘了有obsolete attribute可以用
75F：推 enthos: A、B=>AI程式分析軟體->AI程式產生器->C.再修改成D 02/24 16:54
76F：推 fantasystar: 把共用的部分複製一份出來，弄好unit tests. 開發 C 02/24 18:07
77F：→ fantasystar: 的時候做好integration tests. A/B 的重構 （改成用 02/24 18:07
78F：→ fantasystar: 之前抽出來的模組）就另外跟 product owner 談。 02/24 18:07
79F：推 mathrew: C先抽，AB先暫時放著，等有空再改AB 02/24 19:37
80F：→ MonyemLi: 下個看到你程式的會說同樣的話，無論你又沒有重構 02/24 20:27
81F：→ MonyemLi: 後面有空，不會發生的 02/24 20:29
82F：推 jej: 我會了解這個系統還會多久EOS 02/24 22:12
83F：→ jej: 如果一年內 那就讓他臭吧 02/24 22:12
84F：→ jej: 如果還有很長的路要走 當然重構阿 02/24 22:12
85F：→ jej: 軟體維護的思緒往往和直覺顛倒 02/24 22:12
86F：→ jej: 今天有3個案例再重複 代表很有大的機會往後也要有 02/24 22:12
87F：→ jej: 你今天不重構 就是往後一直痛下去 02/24 22:12
88F：推 TakiDog: 今天你不重構，痛的是自己，那就重構吧 02/24 22:50
89F：推 jack0204: 問主管阿，主管都不在意的話你在意幹嘛 02/24 23:46
90F：→ jack0204: 你可以C額外寫一個引入用的，然後去AB的註解寫todo 02/24 23:47
主管是不在意啦 他也知道重構影響太大了
91F：推 avril9950: 先說服你主管你們的扣超髒，再繼續下去疊床架屋要垮了 02/25 00:31
92F：→ avril9950: ，一直恐嚇他到他願意排時程跟QA讓你重構 02/25 00:31
93F：→ viper9709: 這個很標準的就是先抽C,AB等之後有改的時候再接 02/25 00:46
※ 編輯: VScode (115.43.126.106 臺灣), 02/25/2022 01:16:28
94F：推 j9d9: 選KPI，長期來說不好， 可以考慮換工作 02/25 08:12
95F：推 anandydy529: 以前我是把AB也換成新的，但有人跟我說沒壞的東西為 02/25 10:37
96F：→ anandydy529: 什麼要動，想想也是很有道理 02/25 10:37
97F：推 t64141: 不是沒就不能動，是要有計畫的修正 02/25 10:47
98F：→ t64141: 開發時先求有再求好，維護時沒壞就不動，分開看看 02/25 10:56
99F：→ t64141: 都合理，放在一起常常是悲劇 02/25 10:56
100F：推 youtuuube000: 改了之後有bug客戶一直叫然後公司營收受損這樣有比 02/25 17:08
101F：→ youtuuube000: 較好嗎 02/25 17:08
102F：推 aidansky0989: 他已經爛這麼多年沒事，說明並沒有重 02/26 00:30
103F：→ aidansky0989: 構的價值 02/26 00:30
104F：→ aidansky0989: 你很閒沒事幹可以 02/26 00:31
105F：推 xluds24805: 先上 C，寫測試。上線確認沒問題後再把 A、B 改用 C 02/26 01:38
106F：→ xluds24805: 的新函式 02/26 01:38
107F：推 sunsamy: 建議要入境隨俗 02/26 03:58
108F：→ sunsamy: 要不然你會被程度差的碼農當成你程度差,來亂的! 02/26 03:59
109F：推 jej: 樓上 那是一時的 本肥年輕時也曾經因此被瞧不起 02/26 08:02
110F：→ jej: 前輩們看到就幹譙一次 後來他們不爽公司 離職的離職 02/26 08:02
111F：→ jej: 升遷的升遷 最後剩下要維護的你 繼續因為爛code 被逼到離職 02/26 08:02
112F：噓 pttano: 你應該是菜鳥，兩段code的邏輯相同就要重構？ 02/26 11:33
113F：→ f763guy: 願賭服輸，賭輸別怨 02/26 14:54
114F：→ yourinfo: 寫好C，然後在AB註解就好，以後有人要動AB再改好了 02/26 21:46
115F：→ yourinfo: 有時候花時間做爛了不會有人感謝的，最大限度做好事就好 02/26 21:47
116F：→ daddy29: 再過幾年你會發現其實就是自己能力沒這麼猛 需要時間多 02/27 01:46
117F：→ MonyemLi: 寫詳細點，你們怎麼測試的，人工，那你今天改A,B有人測 02/27 19:14
118F：→ MonyemLi: 嗎？那就是跟挖個機率坑給主管跳。請上報，一路報上去 02/27 19:14
119F：→ MonyemLi: 。不允許，商業理念與你待著幹嗎？但時間壓力加保守主 02/27 19:14
120F：→ MonyemLi: 義下多半不允許。 02/27 19:14
121F：→ iamshiao: 看你打算在這間待多久 03/02 01:58
122F：推 zenuo: 真的照bheegrl說的是比較合理的做法 不影響kpi又先把架構 03/06 00:08
123F：→ zenuo: 做好但不影響實際功能 03/06 00:08
124F：推 hellophoenix: 你好像我以前的同事，剩沒幾天要release然後說要 03/14 01:56
125F：→ hellophoenix: 重構 03/14 01:56