假設以下情境
有個功能A、B都會用到相同邏輯，且有兩份重覆的code
(沒有unit test保護，而且年久失修 要加入unit test會需要更多時程)
現在要加入C，也會用到相同邏輯
身為合格的工程師 應該會把ABC重覆的部份提取出來
而不是讓這邏輯重覆三次
但以公司營運的角度來看 這次專案就只會測試C的部份
不應該動到A、B
這時就要冒著A、B壞掉風險重構，或是因為來不及加入unit test
就乾脆讓相同邏輯存在三個地方
身為專業工程師，我很想選擇重構
但過去的經驗告訴我
絕對要以kpi為最優先考量
於是程式充滿了註解、重覆片段
雖然靠著筆記、git log，能還原當時寫code的思路
但這些髒code就會永遠留存在程式裡
想問大家遇到這情況會怎麼做?

一堆重複程式碼以及註解，真的好髒

要我一定改,既然改就不要單純抽離,用clean code層面思考

為了預防DEFG也用到一樣的東西，至少這次寫乾淨點

會這樣就代表中間業務邏輯更動了,無法遵循open-closed

考績只是一時的，繼續寫爛 code，對職涯發展不好，長期來看就是自廢武功

看你的份量 跟要不要對三個月後的自己好一點

If it ain’t brake , don’t fix it

至少C要寫的話一定會加上unit test

先把C邏輯的泛用性處理好 之後讓A,B可以簡單引用又方便測試大家寫久了多少會有潔癖 但出來工作有時候要克制這種潔癖 尤其負責的專案越大 協同作戰的人又多時 重構的成本可能超乎想像我是覺得未來自己寫的扣 盡量保持乾淨易擴充易讀即可

有錢嗎？有就切沒有就算了老闆不會在意

沒時間就到沒看到，又不是你的問題。有時間也要看公司文化跟趴數夠不夠，改了很容易產生副作用，還要不怕被幹譙

重複跟髒有什麼關係？

先看看A、B壞掉你能負責嗎...

先讓 C 再重複一次，等確認 C 沒問題了再來討論要怎麼重構啊

政治問題 如果出事情你能不能負責

寫的乾淨沒人感激你 前人挖洞 你也一起玩啊 反正專案也是會輪流的 顆顆

工程師搞KPI? 哪間公司啦 說來笑笑

樓上，Amazon 和 Facebook 平時都是你嘲笑的對象嗎？

如果有足夠的時間與把握讓A B C都正常再說吧原本好好的改壞這個問題有時會非常嚴重我應該會新增C但預留了日後整合A/B的彈性或者一口氣改好但先驗證C是OK的再把AB切換過去如果時間不夠的話就不要碰AB了把C做好驗好就好

C大很懂?在哪高就?

看薪水吧 薪水到位 一切好談

先把重複邏輯的地方獨立出來給C用並預備給A、B用，後續有動到A、B的時候再修改？

會問這種問題 就是你的不專業了

歷史包袱啊

過去遇到這情況，我先把共用抽出來給C使用，後面有空再陸續套上A和B以及各自的unit test，這個邏輯可以套用所有你想重構的場景，視情況變化一下而已

如果團隊不想解決 就大家一起放著爛

多做這件事不一定有錢啦，但是熟練以後時間成本會越來越低，久了你就不會再把KPI和clean code放在天秤上衡量半天這個風險跟相信我能反殺差不多高，最好別吧

你可以考慮做C的時候先把和A、B重複的邏輯各別提出來也就寫成C + A~C共用邏輯(假定是兩隻method)你實際上只用寫了C，等以後有人要改A、B時再順便重構就好這樣你概做出彈性來又不用一次性擔太多風險*既

想想看怎麼把重構變成KPI啊

共用部分抽吃來，只有C套用，接著開單做AB重構*抽出來

你可以把C寫成以後DEFG可以用，但先別動AB以後真要改AB時也能引用C，是說很可能以後改AB又另一個故事

為什麼在這裡跟局外人糾結？go talk to your mgr and call adesign session. present pros and cons to your team. this is a team decision, not yours.

有版本跟分支控制不用怕改壞啊

@peter98 敝司某 fortune 20，沒有 kpi 不用為我擔心

現在沒有壞的東西，不要沒事找事做，有空看ptt不好嗎

我之前是用類似藍綠部屬，用一個if控制新舊版本然後用設定檔控制切換，如果發現有錯就立刻切回舊版

理論上是跟你同事討論才對但你重構的夠好 注解就不用寫得像之前那樣了不是嗎？

等C穩定後再逐漸把AB功能加進去，這期間還是繼續用AB，穩點來不要一口氣直接改AB重構很多時候看你年資跟老闆主管挺不挺就是

A B不動但rename加上deprecated，並加註解說明請改用重構過的A’ B’。然後抽出共用模組給A’ B’ C用。這樣以後的人也知道新功能不要再呼叫舊的A B改用A’ B’。

A、B=>AI程式分析軟體->AI程式產生器->C.再修改成D

把共用的部分複製一份出來，弄好unit tests. 開發 C的時候做好integration tests. A/B 的重構 （改成用之前抽出來的模組）就另外跟 product owner 談。

C先抽，AB先暫時放著，等有空再改AB

下個看到你程式的會說同樣的話，無論你又沒有重構後面有空，不會發生的

我會了解這個系統還會多久EOS如果一年內 那就讓他臭吧如果還有很長的路要走 當然重構阿軟體維護的思緒往往和直覺顛倒今天有3個案例再重複 代表很有大的機會往後也要有你今天不重構 就是往後一直痛下去

今天你不重構，痛的是自己，那就重構吧

問主管阿，主管都不在意的話你在意幹嘛你可以C額外寫一個引入用的，然後去AB的註解寫todo

先說服你主管你們的扣超髒，再繼續下去疊床架屋要垮了，一直恐嚇他到他願意排時程跟QA讓你重構

這個很標準的就是先抽C,AB等之後有改的時候再接

選KPI，長期來說不好， 可以考慮換工作

以前我是把AB也換成新的，但有人跟我說沒壞的東西為什麼要動，想想也是很有道理

不是沒就不能動，是要有計畫的修正開發時先求有再求好，維護時沒壞就不動，分開看看都合理，放在一起常常是悲劇

改了之後有bug客戶一直叫然後公司營收受損這樣有比較好嗎

他已經爛這麼多年沒事，說明並沒有重構的價值你很閒沒事幹可以

先上 C，寫測試。上線確認沒問題後再把 A、B 改用 C的新函式

建議要入境隨俗要不然你會被程度差的碼農當成你程度差,來亂的!

樓上 那是一時的 本肥年輕時也曾經因此被瞧不起前輩們看到就幹譙一次 後來他們不爽公司 離職的離職升遷的升遷 最後剩下要維護的你 繼續因為爛code 被逼到離職

你應該是菜鳥，兩段code的邏輯相同就要重構？

願賭服輸，賭輸別怨

寫好C，然後在AB註解就好，以後有人要動AB再改好了有時候花時間做爛了不會有人感謝的，最大限度做好事就好

再過幾年你會發現其實就是自己能力沒這麼猛 需要時間多

寫詳細點，你們怎麼測試的，人工，那你今天改A,B有人測嗎？那就是跟挖個機率坑給主管跳。請上報，一路報上去。不允許，商業理念與你待著幹嗎？但時間壓力加保守主義下多半不允許。

看你打算在這間待多久

真的照bheegrl說的是比較合理的做法 不影響kpi又先把架構做好但不影響實際功能

你好像我以前的同事，剩沒幾天要release然後說要重構