大家中秋节快乐，快收心了。
想问一个假设性问题，大家在工作上，如果有一份专案的 code 是某位前人一手写的
后来新人加入，变成前人带新人，此时继续维护那份code。
但再过一阵子，前人离职了，唯一的创始者走了。
新人把旧 code 重构，或是砍掉重炼的机率高吗？
我的想像是，如果一份code是出自于1个人之手
那么code就是他的世界观、他的切入点
后面的人看着他的世界观，有时候不一定能全部接受
而有人的地方就有政治
当他还在的时候，当然就不会乱动。
而当他走了的时候，后面的人，一看不爽，就可能改写成自己看得爽的、
好改的code。
如果是一个团队，那当然要好好讨论为什么要改
哪些因素造成现在不好的情况，以及主管同不同意改等等的。
只是我很好奇，1,2人的专案，改的机率高吗？
是不是，code只能是“现在还存在公司的人”能控制的才行。
作者:
Dnight (暗夜)
2018-09-24 20:46:00重构的好处在那里，有比重构完整个系统坏掉的风险高吗就算系统重构好可以正常行为，重构花掉的成本算谁的
作者:
xxtuoo (浪费时间不好QQ)
2018-09-24 20:48:00想改就改啊..不过我碰到的都是新人装死..懒得改..责任推给前人XDD
作者:
Dnight (暗夜)
2018-09-24 20:49:00不是说不要乱重构，你重构的好处要大于重构的成本跟风险不然你只是看不顺眼就重构，对之后维护没有特别帮助
一般来说，要重构通常是要加需求但是改不动了只好重构前人有时候规划时写太死，或是架构只有规划的人懂，后人
作者:
lucky1lk (赌到没钱的人)
2018-09-24 20:55:00要看成本阿
维护起来太困难就会打掉重写（小公司可能两三年就一个轮回
作者: t64141 (榕树) 2018-09-24 20:56:00
我的切入点是重构减少未来的维护成本漏字，减少未来多少的维护成本但这得要你老板有技术背景听得懂，或是非常信任你
作者:
CGS0 (Mike Chen)
2018-09-24 20:57:00如果没问题的 code ，重写代表要重测 ，能保証重写的更好吗？
讲得出来怎么改善就改阿 比较怕改完只有风格变了而已
高不高看时间有没有给你 同时新需求跟重构你赶得上吗
作者: frog79110 (尼姆) 2018-09-24 21:00:00
自己偷偷开一个分支改阿XD
要看，重构花时间成本，老板不一定愿意让你做，除非有要加几个大功能或效能改进尤其前人写的很少会有test case
我比较机车 第一款出来之后接着改版UI 然后我觉得我写的很烂所以我多要了一个月砍掉重写 但我没说我全部砍掉重来
作者:
pttworld (批踢踢世界)
2018-09-24 21:22:00通常翻写是换语言，十年以上历史
作者:
yamakazi (大安吴彦祖)
2018-09-24 21:23:00FLAG之流的公司 平均年资也是三到五年 难不成这些公司每三到五年就重构吗
作者:
pttworld (批踢踢世界)
2018-09-24 21:23:00另外一个人只揹一个案子真是太幸福了
作者:
alog (A肉哥)
2018-09-24 21:24:00重构是有工时跟时间成本的 不是你爱干嘛就干嘛XD开这条战线出来你要hold住 不然你没弄好大概变战犯而且很多时候除了设计上要做改善或改良，为了求未来稳定或要完整输入出结果不会因为重构影响 还会有很多test要测
作者:
atpx (秋雨的心情)
2018-09-24 21:29:00看重要性, 越重要越不可能随便重购
作者:
alog (A肉哥)
2018-09-24 21:30:00如果你的问题只是coding style的问题 就看怎么拿捏 因为在少人团队还是会专注于解决当下问题
作者:
atpx (秋雨的心情)
2018-09-24 21:30:00主管宁愿多花几倍成本作测试也不会承担重构坏掉风险
作者:
galic (嘎利)
2018-09-24 21:36:00有一本书 叫做clean code，可以看看
作者:
y3k (激流を制するは静水)
2018-09-24 22:42:00除非有重大瑕疵 否则公司又不是做艺术品 当时没做好的就没做好 像那种程式后面常常会被讲是黑盒子XDD
韧体 重构和porting 前人吃过的硬件屎 还要吃一遍...
作者:
chia7712 (Spright)
2018-09-24 22:58:00对一个已经上production的系统而言，重构跟重新投胎有87%像...
专案数千声音 分类+隐藏规格数十 跨三家IC i/o硬件会错都开卖囉。就问谁敢重构QQ
作者: uller (OminFn) 2018-09-24 23:38:00
有问题谁背 时间太多吗 我会叫你去弄新专案每次离职 code就要重搞 公司又不是疯了
作者: disk249 2018-09-24 23:43:00
很多时候就算你有实力重改，也因为上面的决定无法重做
作者: bug147123 (HowDoYouTurnThisOn) 2018-09-25 00:09:00
会先写好测试再来谈重构
作者:
Masakiad (Masaki)
2018-09-25 00:41:00我们team机率是很高啦，前人留下太多债，现在碰到很多评估再加功能会边难以测试的架构，所以常常重构。
作者:
pooznn (我~~~是来被打脸滴!!!)
2018-09-25 01:18:00这是政治问题 老板87%不会同意花钱 花时间 做同样的东西你的直属长官更不会同意重写 因为这证明以前他走错方向了
作者:
Ghamu (猫丸)
2018-09-25 01:26:00一般是从小做起 摸到的部分开始一点一点重构 而不是 “我他妈要重构全部程式啦！”这样吧
作者: jackylu63 (J) 2018-09-25 06:28:00
我负责的code + 我看不爽 = 翻
翻写ok 但是我经验是，不要有一种自己的优越心态去面对这种code，很多看起来很诡异的workaround都是因为前人碰过某些难以越过的困难才这样做这些困难也许是其他系统造成的 也许真的是一开始就长歪也许现在也不存在，总之，别太狂战士
作者:
qss05 (minami)
2018-09-25 09:36:00除非你能在维持正常工作的情况下还能重写，不然老板干嘛让你花很长的时间停摆现有工作，只为了让你改你觉得不好的东西?这种要嘛是流程已经大改，可是前面的人偷懒用很迂回的方式一直加垃圾，要嘛就是现有方法已经没办法更新新需求或是你的专案重要性不高，不然通常就加减用。除非你能力真的很好，超越了你前面的所有人…
作者:
bobju (枯藤老树昏鸦)
2018-09-25 10:44:00手上多少资源做多少事 吃饱太闲才会想要改改改改不是当下爽就好 要有引发后续种种连动议题的心理准备
作者:
bndan (seed)
2018-09-25 13:03:00时间成本问题 除非有特定原因 EX:想逃避面对旧CODE出的问题或是"期望公司能更上一层楼"等 不然我想像不到"推翻"旧CODE的动机..= =a
作者:
jonyig (是喔喔)
2018-09-25 19:28:00看成本啊
回楼上，会有这种code，通常也不会做 testing ...