跟著一個專案走4年了
當初從無到有打了一段爛帳
現在持續維護跟開發新功能
每每看到以前留下的爛坑
就很不好意思
沒封裝，沒多型
一堆程式碼糾纏在一起
有時想動手重構
又想到現在上commit,很多人會review
也不知適不適合改動已經上線已久的專案
你們會花費力氣去修改以前的爛坑嗎？
作者:
Argos (Big doge is watching u)
2019-01-07 19:11:00對 先問主管 不給時間或不在乎 就放給他爛就好
作者: t64141 (榕樹) 2019-01-07 19:15:00
上面同意就會
作者:
joery (Lin)
2019-01-07 19:40:00同意，如果有時間允許，還是重構一下好。不然那天新需求或修改需求動到那坑更痛苦
作者:
shyangs (厚呦)
2019-01-07 19:46:00先算成本; 規模太大, Netscape 5 的教訓被歷史銘記
作者:
kewang (652公車)
2019-01-07 19:48:00先寫測試
作者:
hotahaha (hey you ROCK MAN!)
2019-01-07 20:23:00問題是沒有時間 (?
作者:
APTON (瑋瑋)
2019-01-07 21:10:00有狀況需要修改的時候再來重構。沒問題好好的幹嘛改？
千萬不要,除非公司要你去重構,不然上線中的東西別亂動
作者: giantwinter 2019-01-07 21:32:00
會
作者: philip80220 (花) 2019-01-07 22:02:00
推樓樓上，上線後，穩定的程式碼比乾淨的程式碼重要太多
作者:
jj0321 (JJ與你倒數唷)
2019-01-07 22:46:00新功能/新專案可以做, 但舊架構變新架構 心臟要很大顆
作者:
iamshiao (CircleHsiao)
2019-01-07 23:22:00剛好有 bug 或擴充就順便改，不然就丟著
作者:
MixBear (米克斯)
2019-01-07 23:51:00不用刻意改，但如果在做新專案會用到或改到那塊程式，就會順手做尤其是重複的 一定想辦法消滅遇過太多擺爛 視而不見，又複製一份來改 久而久之都不知道是刻意還是漏改的 接手時幹死
作者:
yyc1217 (somo)
2019-01-08 00:04:00先補test 再來修改
上線的還改？ 成本非常高 你還要把測試sit uat重跑一輪
作者:
umum29 (....)
2019-01-08 02:49:00我們公司的senior還蠻常refactoring 不過真的要好好測試以前待工廠的MIS 老闆是不鼓勵重構的 產業不同觀念不同
作者:
jasonLu (陸傑森)
2019-01-08 04:13:00沒必要，真的閒到不行也是從有test的專案開始
作者: maxumin (柏青哥代言人) 2019-01-08 06:51:00
已經MP就不要，跨很恐怖
作者:
Csongs (西歌)
2019-01-08 09:00:00沒寫測試 重構找自己麻煩
refactoring 也要有適當的資源，如果什麼測試都沒有，這個專案也上線了且更動幅度不高，風險衡量下來可能不要動還好一點。重構也是有成本和風險的啊。
作者:
overhead (overhead)
2019-01-08 09:19:00一定要有配套的測試才改。不然下場是自己很有自信的認為只是改寫法，不會有問題，但卻壞了
作者:
csfgsj (切割對半)
2019-01-08 09:47:00用OOP 才是在製造爛 code 吧！
作者: alohahsiao 2019-01-08 10:48:00
沒事不要改
作者:
MixBear (米克斯)
2019-01-08 11:21:00用oop是製造爛code? 那是不會用亂用吧
作者:
testPtt (測試)
2019-01-08 13:11:00沒必要 時間到了砍掉重練就好 就像windows一樣
作者: sphoenix 2019-01-08 16:17:00
會
以後寫漂亮點就好了 舊的東西能動 效能沒問題就不要動吧哈
真的想改您要先把每一個步驟寫出來 寫到很細節 然後給主管看 請他背書我的經驗是極其困難 所有之前該測的都要測到 所以要有不錯的自動測試 跟benchmark 才能保證改好的跟原來一樣能動
作者: internetms52 (Oaide) 2019-01-09 18:26:00
如果知道所有邏輯就動，不知道就先不動
作者:
derekQQ (å°å“ˆå“ˆ)
2019-01-09 23:16:00同MixBear
作者: bizer (bizer) 2019-01-12 15:51:00
有時間會改，問題是沒時間