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