[討論] 重構跟kpi的考量

看板Soft_Job作者 (VSisBestIDEinTheWorld)時間2年前 (2022/02/24 01:13), 2年前編輯推噓33(37推 4噓 79→)
留言120則, 50人參與, 2年前最新討論串1/4 (看更多)
假設以下情境 有個功能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://www.ptt.cc/bbs/Soft_Job/M.1645636422.A.77F.html ※ 編輯: VScode (115.43.126.106 臺灣), 02/24/2022 01:14:25
→
02/24 01:17, 2年前 , 1F
一堆重複程式碼以及註解，真的好髒
02/24 01:17, 1F
推
02/24 01:21, 2年前 , 2F
要我一定改,既然改就不要單純抽離,用clean code層面思考
02/24 01:21, 2F
推
02/24 01:23, 2年前 , 3F
為了預防DEFG也用到一樣的東西，至少這次寫乾淨點
02/24 01:23, 3F
→
02/24 01:24, 2年前 , 4F
會這樣就代表中間業務邏輯更動了,無法遵循open-closed
02/24 01:24, 4F
對 看似重覆 卻有一點地方不太一樣
推
02/24 01:32, 2年前 , 5F
考績只是一時的，繼續寫爛 code，對職涯發展不好，長期
02/24 01:32, 5F
→
02/24 01:32, 2年前 , 6F
來看就是自廢武功
02/24 01:32, 6F
我也是這樣想 不想為了kpi昧著良心
→
02/24 01:44, 2年前 , 7F
看你的份量 跟要不要對三個月後的自己好一點
02/24 01:44, 7F
這倒是還好 這個地方的code好幾年沒動了
推
02/24 01:46, 2年前 , 8F
If it ain’t brake , don’t fix it
02/24 01:46, 8F
→
02/24 01:46, 2年前 , 9F
至少C要寫的話一定會加上unit test
02/24 01:46, 9F
→
02/24 01:47, 2年前 , 10F
先把C邏輯的泛用性處理好 之後讓A,B可以簡單引用又方便
02/24 01:47, 10F
→
02/24 01:47, 2年前 , 11F
測試
02/24 01:47, 11F
推
02/24 01:51, 2年前 , 12F
大家寫久了多少會有潔癖 但出來工作有時候要克制這種潔
02/24 01:51, 12F
→
02/24 01:51, 2年前 , 13F
癖 尤其負責的專案越大 協同作戰的人又多時 重構的成本
02/24 01:51, 13F
→
02/24 01:51, 2年前 , 14F
可能超乎想像
02/24 01:51, 14F
是啊 功能複雜的地方要重構 要有很完整的測試
推
02/24 01:53, 2年前 , 15F
我是覺得未來自己寫的扣 盡量保持乾淨易擴充易讀即可
02/24 01:53, 15F
推
02/24 01:55, 2年前 , 16F
有錢嗎？有就切沒有就算了老闆不會在意
02/24 01:55, 16F
→
02/24 01:58, 2年前 , 17F
沒時間就到沒看到，又不是你的問題。有時間也要看公司文
02/24 01:58, 17F
→
02/24 01:58, 2年前 , 18F
化跟趴數夠不夠，改了很容易產生副作用，還要不怕被幹譙
02/24 01:58, 18F
噓
02/24 02:01, 2年前 , 19F
重複跟髒有什麼關係？
02/24 02:01, 19F
→
02/24 02:12, 2年前 , 20F
先看看A、B壞掉你能負責嗎...
02/24 02:12, 20F
kpi會很慘...
推
02/24 02:20, 2年前 , 21F
02/24 02:20, 21F
推
02/24 03:13, 2年前 , 22F
先讓 C 再重複一次，等確認 C 沒問題了再來討論要怎麼重
02/24 03:13, 22F
→
02/24 03:13, 2年前 , 23F
構啊
02/24 03:13, 23F
推
02/24 03:58, 2年前 , 24F
政治問題 如果出事情你能不能負責
02/24 03:58, 24F
推
02/24 05:40, 2年前 , 25F
寫的乾淨沒人感激你 前人挖洞 你也一起玩啊 反正專案
02/24 05:40, 25F
→
02/24 05:40, 2年前 , 26F
也是會輪流的 顆顆
02/24 05:40, 26F
噓
02/24 05:49, 2年前 , 27F
工程師搞KPI? 哪間公司啦 說來笑笑
02/24 05:49, 27F
推
02/24 05:55, 2年前 , 28F
樓上，Amazon 和 Facebook 平時都是你嘲笑的對象嗎？
02/24 05:55, 28F
→
02/24 06:07, 2年前 , 29F
如果有足夠的時間與把握讓A B C都正常再說吧
02/24 06:07, 29F
→
02/24 06:08, 2年前 , 30F
原本好好的改壞這個問題有時會非常嚴重
02/24 06:08, 30F
→
02/24 06:09, 2年前 , 31F
我應該會新增C但預留了日後整合A/B的彈性
02/24 06:09, 31F
→
02/24 06:10, 2年前 , 32F
或者一口氣改好但先驗證C是OK的再把AB切換過去
02/24 06:10, 32F
→
02/24 06:13, 2年前 , 33F
如果時間不夠的話就不要碰AB了把C做好驗好就好
02/24 06:13, 33F
嗯嗯 我覺得我應該會這樣做 等未來要改A B時，再重構A B
還有 49 則推文
還有 7 段內文
→
02/24 22:12, 2年前 , 83F
如果一年內 那就讓他臭吧
02/24 22:12, 83F
→
02/24 22:12, 2年前 , 84F
如果還有很長的路要走 當然重構阿
02/24 22:12, 84F
→
02/24 22:12, 2年前 , 85F
軟體維護的思緒往往和直覺顛倒
02/24 22:12, 85F
→
02/24 22:12, 2年前 , 86F
今天有3個案例再重複 代表很有大的機會往後也要有
02/24 22:12, 86F
→
02/24 22:12, 2年前 , 87F
你今天不重構 就是往後一直痛下去
02/24 22:12, 87F
推
02/24 22:50, 2年前 , 88F
今天你不重構，痛的是自己，那就重構吧
02/24 22:50, 88F
推
02/24 23:46, 2年前 , 89F
問主管阿，主管都不在意的話你在意幹嘛
02/24 23:46, 89F
→
02/24 23:47, 2年前 , 90F
你可以C額外寫一個引入用的，然後去AB的註解寫todo
02/24 23:47, 90F
主管是不在意啦 他也知道重構影響太大了
推
02/25 00:31, 2年前 , 91F
先說服你主管你們的扣超髒，再繼續下去疊床架屋要垮了
02/25 00:31, 91F
→
02/25 00:31, 2年前 , 92F
，一直恐嚇他到他願意排時程跟QA讓你重構
02/25 00:31, 92F
→
02/25 00:46, 2年前 , 93F
這個很標準的就是先抽C,AB等之後有改的時候再接
02/25 00:46, 93F
※ 編輯: VScode (115.43.126.106 臺灣), 02/25/2022 01:16:28
推
02/25 08:12, 2年前 , 94F
選KPI，長期來說不好， 可以考慮換工作
02/25 08:12, 94F
推
02/25 10:37, 2年前 , 95F
以前我是把AB也換成新的，但有人跟我說沒壞的東西為
02/25 10:37, 95F
→
02/25 10:37, 2年前 , 96F
什麼要動，想想也是很有道理
02/25 10:37, 96F
推
02/25 10:47, 2年前 , 97F
不是沒就不能動，是要有計畫的修正
02/25 10:47, 97F
→
02/25 10:56, 2年前 , 98F
開發時先求有再求好，維護時沒壞就不動，分開看看
02/25 10:56, 98F
→
02/25 10:56, 2年前 , 99F
都合理，放在一起常常是悲劇
02/25 10:56, 99F
推
02/25 17:08, 2年前 , 100F
改了之後有bug客戶一直叫然後公司營收受損這樣有比
02/25 17:08, 100F
→
02/25 17:08, 2年前 , 101F
較好嗎
02/25 17:08, 101F
推
02/26 00:30, 2年前 , 102F
他已經爛這麼多年沒事，說明並沒有重
02/26 00:30, 102F
→
02/26 00:30, 2年前 , 103F
構的價值
02/26 00:30, 103F
→
02/26 00:31, 2年前 , 104F
你很閒沒事幹可以
02/26 00:31, 104F
推
02/26 01:38, 2年前 , 105F
先上 C，寫測試。上線確認沒問題後再把 A、B 改用 C
02/26 01:38, 105F
→
02/26 01:38, 2年前 , 106F
的新函式
02/26 01:38, 106F
推
02/26 03:58, 2年前 , 107F
建議要入境隨俗
02/26 03:58, 107F
→
02/26 03:59, 2年前 , 108F
要不然你會被程度差的碼農當成你程度差,來亂的!
02/26 03:59, 108F
推
02/26 08:02, 2年前 , 109F
樓上 那是一時的 本肥年輕時也曾經因此被瞧不起
02/26 08:02, 109F
→
02/26 08:02, 2年前 , 110F
前輩們看到就幹譙一次 後來他們不爽公司 離職的離職
02/26 08:02, 110F
→
02/26 08:02, 2年前 , 111F
升遷的升遷 最後剩下要維護的你 繼續因為爛code 被逼到離職
02/26 08:02, 111F
噓
02/26 11:33, 2年前 , 112F
你應該是菜鳥，兩段code的邏輯相同就要重構？
02/26 11:33, 112F
→
02/26 14:54, 2年前 , 113F
願賭服輸，賭輸別怨
02/26 14:54, 113F
→
02/26 21:46, 2年前 , 114F
寫好C，然後在AB註解就好，以後有人要動AB再改好了
02/26 21:46, 114F
→
02/26 21:47, 2年前 , 115F
有時候花時間做爛了不會有人感謝的，最大限度做好事就好
02/26 21:47, 115F
→
02/27 01:46, 2年前 , 116F
再過幾年你會發現其實就是自己能力沒這麼猛 需要時間多
02/27 01:46, 116F
→
02/27 19:14, 2年前 , 117F
寫詳細點，你們怎麼測試的，人工，那你今天改A,B有人測
02/27 19:14, 117F
→
02/27 19:14, 2年前 , 118F
嗎？那就是跟挖個機率坑給主管跳。請上報，一路報上去
02/27 19:14, 118F
→
02/27 19:14, 2年前 , 119F
。不允許，商業理念與你待著幹嗎？但時間壓力加保守主
02/27 19:14, 119F
→
02/27 19:14, 2年前 , 120F
義下多半不允許。
02/27 19:14, 120F
‣ 更多 VScode 的文章
文章代碼(AID): #1Y5cj6T_ (Soft_Job)
討論串 (同標題文章)
以下文章回應了本文 (最舊先)：
完整討論串 (本文為第 1 之 4 篇)：
排序： 最舊先 | 最新先 | 留言數
在新視窗開啟完整討論串 (共4篇)
‣ 更多 VScode 的文章
文章代碼(AID): #1Y5cj6T_ (Soft_Job)