跟着一个专案走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
有时间会改，问题是没时间