推 Dnight: 重構的好處在那裡，有比重構完整個系統壞掉的風險高嗎 09/24 20:46
→ Dnight: 就算系統重構好可以正常行為，重構花掉的成本算誰的 09/24 20:46
所以大大的經驗是 東西沒壞 就不要亂重構嗎？
※ 編輯: peanut97 (124.6.15.211), 09/24/2018 20:48:15
推 xxtuoo: 想改就改啊..不過我碰到的都是新人裝死..懶得改..責任推給 09/24 20:48
→ xxtuoo: 前人XDD 09/24 20:48
推 Dnight: 不是說不要亂重構，你重構的好處要大於重構的成本跟風險 09/24 20:49
→ Dnight: 不然你只是看不順眼就重構，對之後維護沒有特別幫助 09/24 20:50
我知道要看目的，以及成本~ 是想問最後結果會重構的機率高不高XD 八卦一下
→ dalconan: 一般來說，要重構通常是要加需求但是改不動了只好重構 09/24 20:54
→ dalconan: 前人有時候規劃時寫太死，或是架構只有規劃的人懂，後人 09/24 20:54
→ lucky1lk: 要看成本阿 09/24 20:55
是的~ 但想問最後結果是會還是不會XD
→ dalconan: 維護起來太困難就會打掉重寫（小公司可能兩三年就一個輪 09/24 20:55
→ dalconan: 迴 09/24 20:55
感謝回應
※ 編輯: peanut97 (124.6.15.211), 09/24/2018 20:56:43
→ t64141: 我的切入點是重構減少未來的維護成本 09/24 20:56
→ t64141: 漏字，減少未來多少的維護成本 09/24 20:56
※ 編輯: peanut97 (124.6.15.211), 09/24/2018 20:57:54
→ t64141: 但這得要你老闆有技術背景聽得懂，或是非常信任你 09/24 20:57
推 CGS0: 如果沒問題的 code ，重寫代表要重測 ，能保証重寫的更好嗎 09/24 20:57
→ CGS0: ？ 09/24 20:57
推 clamperni: 講得出來怎麼改善就改阿 比較怕改完只有風格變了而已 09/24 20:57
→ MOONY135: 高不高看時間有沒有給你 同時新需求跟重構你趕得上嗎 09/24 20:59
推 frog79110: 自己偷偷開一個分支改阿XD 09/24 21:00
推 doranako: 要看，重構花時間成本，老闆不一定願意讓你做，除非有 09/24 21:03
→ doranako: 要加幾個大功能或效能改進 09/24 21:03
→ doranako: 尤其前人寫的很少會有test case 09/24 21:05
→ MOONY135: 我比較機車 第一款出來之後接著改版UI 然後我覺得我寫的 09/24 21:08
→ MOONY135: 很爛所以我多要了一個月砍掉重寫 但我沒說我全部砍掉重 09/24 21:08
→ MOONY135: 來 09/24 21:08
→ pttworld: 通常翻寫是換語言，十年以上歷史 09/24 21:22
推 yamakazi: FLAG之流的公司 平均年資也是三到五年 難不成這些公司每 09/24 21:23
→ yamakazi: 三到五年就重構嗎 09/24 21:23
→ pttworld: 另外一個人只揹一個案子真是太幸福了 09/24 21:23
→ alog: 重構是有工時跟時間成本的 不是你愛幹嘛就幹嘛XD 09/24 21:24
推 alog: 開這條戰線出來你要hold住 不然你沒弄好大概變戰犯 09/24 21:26
推 alog: 而且很多時候除了設計上要做改善或改良，為了求未來穩定或要 09/24 21:28
→ alog: 完整輸入出結果不會因為重構影響 還會有很多test要測 09/24 21:28
推 atpx: 看重要性, 越重要越不可能隨便重購 09/24 21:29
推 alog: 如果你的問題只是coding style的問題 就看怎麼拿捏 因為在 09/24 21:30
→ alog: 少人團隊還是會專注於解決當下問題 09/24 21:30
→ atpx: 主管寧願多花幾倍成本作測試也不會承擔重構壞掉風險 09/24 21:30
→ alog: 重構要長期維護跟遇到真實的瓶頸或遇到設計、擴充上的問題才 09/24 21:30
→ alog: 會動刀 09/24 21:30
→ alog: 一個系統的核心程式非常多 你重構幾個小部分是沒有意義的 09/24 21:31
→ galic: 有一本書 叫做clean code，可以看看 09/24 21:36
噓 smallcar801: 正常智商的老闆不會讓你這樣幹 09/24 22:06
推 lovebridget: 幹嘛翻 花自己時間耶 又不是自己公司 09/24 22:38
推 y3k: 除非有重大瑕疵 否則公司又不是做藝術品 當時沒做好的就沒做 09/24 22:42
→ y3k: 好 像那種程式後面常常會被講是黑盒子XDD 09/24 22:42
→ fgkor123: 韌體 重構和porting 前人吃過的硬體屎 還要吃一遍... 09/24 22:58
推 chia7712: 對一個已經上production的系統而言，重構跟重新投胎有87 09/24 22:58
→ chia7712: %像... 09/24 22:58
→ fgkor123: 專案數千聲音 分類+隱藏規格數十 跨三家IC i/o硬體會錯 09/24 23:02
→ fgkor123: 都開賣囉。就問誰敢重構QQ 09/24 23:03
→ MOONY135: 我一介小小打工仔 還是pass 09/24 23:15
推 uller: 有問題誰背 時間太多嗎 我會叫你去弄新專案 09/24 23:38
→ uller: 每次離職 code就要重搞 公司又不是瘋了 09/24 23:39
→ disk249: 很多時候就算你有實力重改，也因為上面的決定無法重做 09/24 23:43
推 bug147123: 會先寫好測試再來談重構 09/25 00:09
推 Masakiad: 我們team機率是很高啦，前人留下太多債，現在碰到很多 09/25 00:41
→ Masakiad: 評估再加功能會邊難以測試的架構，所以常常重構。 09/25 00:41
→ pooznn: 這是政治問題 老闆87%不會同意花錢 花時間 做同樣的東西 09/25 01:18
→ pooznn: 你的直屬長官更不會同意重寫 因為這證明以前他走錯方向了 09/25 01:19
推 Ghamu: 一般是從小做起 摸到的部分開始一點一點重構 而不是 「我他 09/25 01:26
→ Ghamu: 媽要重構全部程式啦！」這樣吧 09/25 01:26
推 jackylu63: 我負責的code + 我看不爽 = 翻 09/25 06:28
推 Killercat: 翻寫ok 但是我經驗是，不要有一種自己的優越心態去面對 09/25 08:16
→ Killercat: 這種code，很多看起來很詭異的workaround都是因為前人 09/25 08:16
→ Killercat: 碰過某些難以越過的困難才這樣做 09/25 08:16
→ Killercat: 這些困難也許是其他系統造成的 也許真的是一開始就長歪 09/25 08:17
→ Killercat: 也許現在也不存在，總之，別太狂戰士 09/25 08:18
→ qss05: 除非你能在維持正常工作的情況下還能重寫，不然老闆幹嘛讓 09/25 09:36
→ qss05: 你花很長的時間停擺現有工作，只為了讓你改你覺得不好的東 09/25 09:36
→ qss05: 西?這種要嘛是流程已經大改，可是前面的人偷懶用很迂迴的 09/25 09:37
→ qss05: 方式一直加垃圾，要嘛就是現有方法已經沒辦法更新新需求或 09/25 09:37
→ qss05: 是你的專案重要性不高，不然通常就加減用。除非你能力真的 09/25 09:37
→ qss05: 很好，超越了你前面的所有人… 09/25 09:37
→ bobju: 手上多少資源做多少事 吃飽太閒才會想要改改改 09/25 10:44
→ bobju: 改不是當下爽就好 要有引發後續種種連動議題的心理準備 09/25 10:46
→ bndan: 時間成本問題 除非有特定原因 EX:想逃避面對舊CODE出的問題 09/25 13:03
→ bndan: 或是"期望公司能更上一層樓"等 不然我想像不到"推翻"舊CODE 09/25 13:04
→ bndan: 的動機..= =a 09/25 13:04
推 jonyig: 看成本啊 09/25 19:28
噓 KanzakiHAria: Test Case全pass想怎麼改誰管你 09/26 07:52
推 banqhsia: 回樓上，會有這種code，通常也不會做 testing ... 09/26 11:39