[討論] 重構跟kpi的考量

軟工

53333

假設以下情境

有個功能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
labbat1樓一堆重複程式碼以及註解,真的好髒 02/24 01:17
acgotaku2樓要我一定改,既然改就不要單純抽離,用clean code層面思考 02/24 01:21
devilkool3樓為了預防DEFG也用到一樣的東西,至少這次寫乾淨點 02/24 01:23
acgotaku4樓會這樣就代表中間業務邏輯更動了,無法遵循open-closed 02/24 01:24
對 看似重覆 卻有一點地方不太一樣
f496328mm5樓考績只是一時的,繼續寫爛 code,對職涯發展不好,長期 02/24 01:32
f496328mm6樓來看就是自廢武功 02/24 01:32
我也是這樣想 不想為了kpi昧著良心
yyc12177樓看你的份量 跟要不要對三個月後的自己好一點 02/24 01:44
這倒是還好 這個地方的code好幾年沒動了
wadechen8樓If it ain’t brake , don’t fix it 02/24 01:46
yyc12179樓至少C要寫的話一定會加上unit test 02/24 01:46
wadechen10樓先把C邏輯的泛用性處理好 之後讓A,B可以簡單引用又方便 02/24 01:47
wadechen11樓測試 02/24 01:47
wadechen12樓大家寫久了多少會有潔癖 但出來工作有時候要克制這種潔 02/24 01:51
wadechen13樓癖 尤其負責的專案越大 協同作戰的人又多時 重構的成本 02/24 01:51
wadechen14樓可能超乎想像 02/24 01:51
是啊 功能複雜的地方要重構 要有很完整的測試
wadechen15樓我是覺得未來自己寫的扣 盡量保持乾淨易擴充易讀即可 02/24 01:53
neo527716樓有錢嗎?有就切沒有就算了老闆不會在意 02/24 01:55
angusyu17樓沒時間就到沒看到,又不是你的問題。有時間也要看公司文 02/24 01:58
angusyu18樓化跟趴數夠不夠,改了很容易產生副作用,還要不怕被幹譙 02/24 01:58
MoonCode19樓重複跟髒有什麼關係? 02/24 02:01
asadman152320樓先看看A、B壞掉你能負責嗎... 02/24 02:12
kpi會很慘...
MoonCode21樓 02/24 02:20
CoNsTaR22樓先讓 C 再重複一次,等確認 C 沒問題了再來討論要怎麼重 02/24 03:13
CoNsTaR23樓構啊 02/24 03:13
ctrlbreak24樓政治問題 如果出事情你能不能負責 02/24 03:58
airtsubasa25樓寫的乾淨沒人感激你 前人挖洞 你也一起玩啊 反正專案 02/24 05:40
airtsubasa26樓也是會輪流的 顆顆 02/24 05:40
peter9827樓工程師搞KPI? 哪間公司啦 說來笑笑 02/24 05:49
CoNsTaR28樓樓上,Amazon 和 Facebook 平時都是你嘲笑的對象嗎? 02/24 05:55
james73229樓如果有足夠的時間與把握讓A B C都正常再說吧 02/24 06:07
james73230樓原本好好的改壞這個問題有時會非常嚴重 02/24 06:08