推 space20021: 推 09/14 11:17
推 mozume: 這個故事好眼熟，應該在很多地方發生過 09/14 11:33
推 tsaigi: 推 09/14 11:35
推 kurtsgm: XD 看完這鬼故事笑了 但我好奇切換到A module之後是大爆 09/14 11:37
→ kurtsgm: 炸還是真的順利完成迭代 09/14 11:37
我不知道 我離職前還AB兩個版本都還在雙軌運行 算是開放式結局
※ 編輯: SkankHunt42 (154.47.23.51 日本), 09/14/2025 11:49:46
→ fgh81113: 那A幹嘛生類似的功能？是因為通通都要用B的程式？ 09/14 12:38
推 jack0204: 可以強烈建議但不能不說直接做，因為責任是決定的人扛 09/14 12:52
→ jack0204: 分兩個版本不是不行，但要想好怎麼做才不會失敗 09/14 12:54
噓 lturtsamuel: 你這又不是重構 是重寫 先搞清楚問題在哪== 09/14 12:54
你琢磨是重構還是重寫 問題的本質有變嗎
甲大刀闊斧重構 diff佔整個module 80%
跟乙大規模重寫 diff佔整個module 80%
你覺得區別在哪？ 有人會在意你的commit是用什麼方法論嗎
改程式碼就改程式碼 不會因為你給他一個新的名字改變本質
→ jack0204: 我是覺得RD應該要多了解infra相關知識才能避免一些問題 09/14 12:56
※ 編輯: SkankHunt42 (155.2.216.9 日本), 09/14/2025 13:00:52
→ lturtsamuel: 重構就是要限縮範圍 第一步是把一大坨屎改成許多坨小 09/14 13:05
→ lturtsamuel: 屎 再把每一坨屎改正 中間每一步都要有足夠的信心才 09/14 13:05
→ lturtsamuel: 能走下去 當然這是理想情況很難完全做到 但你這做法 09/14 13:05
→ lturtsamuel: 跟理想情況也差太多？ 09/14 13:05
這作法又不是我發明的 關我屁事XD
我入職時就已經是AB雙軌並行了
我從B Team離職前就跟A team主管講了阿 為什麼重構不用局部迭代的方式
他也說不上來阿 就說這是一次錯誤的經驗
原PO內文講的改動幅度我覺得不低啦 所以才舉這個例子
你程式碼差異幅度大到一個程度 本來就會被challenge
你講的小屎逐步翻新那是常規狀況 工作看到就要順便修
有些重構是為了滿足新feature就要整個模組架構跟流程改動的
那種PR一般不會小
※ 編輯: SkankHunt42 (155.2.216.9 日本), 09/14/2025 13:13:05
→ lturtsamuel: 等整個東西都99%完成了才要對接 當然就是重寫啊== 09/14 13:06
→ watashino: 有改動AB test不是很正常嗎 09/14 13:09
推 gino0717: 我覺得維持兩年換一份工作的良好職涯紀律可以避免這些事 09/14 13:21
推 viper9709: 推人的問題最大+1 09/14 17:07
→ MoonCode: 有測試是要先針對舊系統寫 再來新系統測試 09/14 17:22
→ lucky4283: A team是不是太閒，還有時間做重複的功能 09/14 21:04
→ xam: 可以考慮job rotation吧.. 看是搬一些人過去或是兩team互換 09/14 21:18
推 darkMood: 不意外啊。 09/15 00:25
推 marra: 故事好聽，給讚！^_^ 09/15 03:30
推 CRPKT: 重構有具體定義的啦，你要能確保行為不改變才是重構 09/15 11:17
推 GooglePixel: 馬上又有槓精跳出來 最後一段推給每一個人 09/15 11:18
→ CRPKT: 很多時候靠既有手段重構無法走到你想要的地方 09/15 11:18
→ CRPKT: 那個時候跳一小步就已經是重寫了，重寫很正常 09/15 11:19
→ CRPKT: 是不用太糾結名詞，但的確太多人重寫都說自己在重構 09/15 11:20
推 satanmaggie: 好讚，最喜歡開放式結局 09/15 12:45
→ jonathan793: 喜歡你暖暖的文字 09/15 17:08
推 holebro: 好聽的故事 期待多多分享 09/16 16:04
推 lwecloud: A team蠻爽的，不用maintain屎code沒產值還不會被lay 09/16 23:08
推 tim96tim: 幹 真好聽 09/18 19:56