我这篇写的跟原原PO的状况无关
※ 引述《tbpfs ( http://pse.is/tbpfs )》之铭言：
: 其实我真的不懂为什么要急着重构
: 有好处吗?
: 一般而言，重构都是发生在农闲的时候
重构有好处, 而且有不得不做的状况
我曾经遇到效能瓶颈,
发现是在整个流程顺序上只要重新调整并安插几个预处理的阶段就能大幅提升效能
但原本的code就不是很clean, 随便一个method破500行, 一个class有7、80个method
有二十多个boolean变量当作flag在控制状态(但其实只要用3个变量就能搞定)
并且没有unit test作保护
所以:
1. 花时间补unit test、再重构
2. 重写
2当然最不实际, 1很多公司也不会认同, 所以最后就是直接做重构,
效能最后当然是有出来, 可读性也提升很多
但老实讲, 做的真的很痛苦
平时顺手整理code那当然是举手之劳
用千行来计的重构绝对不想再做一次, 重构完bug还算你头上, 爽只有爽到别人而已
很多老鸟应该都知道了，这边建议刚出社会的新鲜人：
就算你知道重构能够大幅提升效能改善可读性,
也要装作不知道, 更不要主动提出重构
被你重构code的人可能会不爽你,
自己做了工作还变多 钱还是一样,
爽只有爽到其他同事而已
公司大家写哪种code就跟着写哪种, 写烂code搞得难维护更显得你重要, 反正pm也不懂

我个人很难对这种无可奈何妥协，所以我宁愿改的很痛苦，我也不写粪扣，反正大不了就开除我也没差

大家好像很害怕重构 如果是以TDD开发的话 重构只是其中一个步骤而已 如果重构没有建立在单元测试上 那重构可能会提早结束你的职业生涯

台湾应该是要重构就块陶吧= = 单元测试只能保护你加功能的时候不要弄坏

依据Martin Fowler的定义“在不改变软件外部行为的前提下，改变其内部结构，使其更容易理解且易于修改 ”，我的认知是重构并不是效能优化而是增加可阅读性，如果没有以单元测试案例为基础，那么重构就是在增加引入bug的机会

原po的例子应该是他要先重构别人的code才有办法加优化的功能进去，这种就常常改也不是，不改也不是。但是”在台湾”，要嘛重构就默默做完不要声张，顶多就是签入时留个到此一游注解深藏功与名，要嘛就是你位置足够高，可以主导架构或专案方向跟时程，不然很多时候都是自找麻烦。

只能在开发相关功能时顺手改 这样才会测到比较保险

如果我要重构1万行的程式 我还是会先写单元测试 但如果考虑时程压力 这种技术债的东西谁接谁倒楣

推先写测试再重构，上线没写测试重构根本搞事

有测试重构才舒服啊，改完跑测试全过就舒坦，但写测试才是真正地狱XD

另外接收别人的code重构 ，根本吃力不讨好

虽然闭着眼睛良心上很痛苦...但是也只能等产品整个周命期过..

我有看过拿着重构去跟公司要时间的人，通常都是.....上面会说你想重构是你的事情 但时间到东西还是要出来

个人满喜欢加新功能时顺便重构 还好本来就有unit test

重构如果不算考绩, 然后还被靠腰说那是你自己平常就要维护的 你就不会想重构了

但有些code一整包杂在一起，很难在重构前先有单元测试..

我们公司反而很鼓励重构，因为产品已经发展成熟没什么事做，只好常常重构来硬挤出一点事做

测试如果写得比待测程式更复杂，也只会增加维护困难吧..

这才是职场真实环境

增改需求时顺便重构，这样出 bug 比较好解释，否则就只能特别找出维护/效能上的改善点来说

这跟重构的定义不一样吧 根本不是重构 已经是为了效能提升做的新功能了这只说明你们公司在开发 feature 根本没有做测试而已 XD

是说写 test 也只能测到已知的问题, 我意见跟楼上一样,这是重新开发新功能了. XD另外重构不会碰到一万行还是一千行的问题,重构就是涵盖问题一万行或一千行没有差别, 做法都是一样的.

推一楼