作者EricTCartman (阿ㄆㄧㄚˇ)
看板Soft_Job
标题Re: [请益] 这种情况要怎麽重构
时间Thu Jun 25 09:46:44 2020
我这篇写的跟原原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也不懂
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 36.231.112.12 (台湾)
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1593049606.A.118.html
1F：→ leo5916267: 我个人很难对这种无可奈何妥协，所以我宁愿改的很痛 06/25 10:32
2F：→ leo5916267: 苦，我也不写粪扣，反正大不了就开除我也没差 06/25 10:32
3F：推 ura1210: 大家好像很害怕重构 如果是以TDD开发的话 重构只是其中 06/25 10:36
就我所知国内不少公司是没有在run tdd, 就算有, 稍有年纪的公司还是会有legacy code
4F：→ ura1210: 一个步骤而已 如果重构没有建立在单元测试上 那重构可能 06/25 10:36
5F：→ ura1210: 会提早结束你的职业生涯 06/25 10:36
重构当然还是从简单的整理开始做起, snippet内的逻辑是能够确认的;
我觉得把单元测试与重构的成功与否画上等号是有点诡异的
※ 编辑: EricTCartman (36.231.112.12 台湾), 06/25/2020 10:47:11
6F：推 Nitricacid: 台湾应该是要重构就块陶吧= = 单元测试只能保护你加 06/25 11:07
7F：→ Nitricacid: 功能的时候不要弄坏 06/25 11:07
8F：推 ura1210: 依据Martin Fowler的定义「在不改变软体外部行为的前提 06/25 11:10
9F：→ ura1210: 下，改变其内部结构，使其更容易理解且易於修改 」，我 06/25 11:10
10F：→ ura1210: 的认知是重构并不是效能优化而是增加可阅读性，如果没有 06/25 11:10
11F：→ ura1210: 以单元测试案例为基础，那麽重构就是在增加引入bug的机 06/25 11:10
12F：→ ura1210: 会 06/25 11:10
假设有10000行code, 流程会参考某个物件的状态而变化,
今天重构其中100行, 在这100行内改变该物件的状态, 补了测试也证明该单元没有错
但除此之外还有9900行, 实务上你也会把那9900行的测试补完才继续重构吗?
※ 编辑: EricTCartman (36.231.112.12 台湾), 06/25/2020 11:22:56
13F：推 TAKADO: 原po的例子应该是他要先重构别人的code才有办法加优化的功 06/25 11:21
14F：→ TAKADO: 能进去，这种就常常改也不是，不改也不是。但是”在台湾” 06/25 11:21
15F：→ TAKADO: ，要嘛重构就默默做完不要声张，顶多就是签入时留个到此一 06/25 11:21
16F：→ TAKADO: 游注解深藏功与名，要嘛就是你位置足够高，可以主导架构或 06/25 11:21
17F：→ TAKADO: 专案方向跟时程，不然很多时候都是自找麻烦。 06/25 11:21
18F：推 vi000246: 只能在开发相关功能时顺手改 这样才会测到比较保险 06/25 11:36
19F：→ ura1210: 如果我要重构1万行的程式 我还是会先写单元测试 但如果 06/25 11:45
20F：→ ura1210: 考虑时程压力 这种技术债的东西谁接谁倒楣 06/25 11:45
21F：推 Csongs: 推先写测试再重构，上线没写测试重构根本搞事 06/25 12:03
22F：推 jack529: 有测试重构才舒服啊，改完跑测试全过就舒坦，但写测试才 06/25 12:05
23F：→ jack529: 是真正地狱XD 06/25 12:05
24F：推 Csongs: 另外接收别人的code重构 ，根本吃力不讨好 06/25 12:07
25F：推 kingofsdtw: 虽然闭着眼睛良心上很痛苦... 06/25 12:11
26F：→ kingofsdtw: 但是也只能等产品整个周命期过.. 06/25 12:12
27F：→ MOONY135: 我有看过拿着重构去跟公司要时间的人，通常都是..... 06/25 12:14
28F：→ MOONY135: 上面会说你想重构是你的事情 但时间到东西还是要出来 06/25 12:15
29F：推 devilkool: 个人满喜欢加新功能时顺便重构 还好本来就有unit test 06/25 12:15
30F：推 seal0112: 重构如果不算考绩, 然後还被靠腰说那是你自己平常就要维 06/25 12:25
31F：→ seal0112: 护的 你就不会想重构了 06/25 12:25
32F：推 comicat: 但有些code一整包杂在一起，很难在重构前先有单元测试.. 06/25 12:26
33F：推 yamakazi: 我们公司反而很鼓励重构，因为产品已经发展成熟没什麽事 06/25 12:26
34F：→ yamakazi: 做，只好常常重构来硬挤出一点事做 06/25 12:26
35F：→ comicat: 测试如果写得比待测程式更复杂，也只会增加维护困难吧.. 06/25 12:27
36F：推 tvbic: 这才是职场真实环境 06/25 12:45
37F：→ t64141: 增改需求时顺便重构，这样出 bug 比较好解释，否则就只能 06/25 14:44
38F：→ t64141: 特别找出维护/效能上的改善点来说 06/25 14:44
39F：推 Gaitz: 这跟重构的定义不一样吧 根本不是重构 已经是为了效能提升 06/25 17:08
40F：→ Gaitz: 做的新功能了 06/25 17:08
不是重构; 但没重构很难做改善.
重构途中也有可能踢掉重复、冗余的计算部分
41F：→ Gaitz: 这只说明你们公司在开发 feature 根本没有做测试而已 XD 06/25 17:09
是针对10年前的code进行效能提升, 我不觉得提升效能算是做一个新feature
legacy code没做测试这是大家都知道的事
42F：→ TonyQ: 是说写 test 也只能测到已知的问题, 我意见跟楼上一样, 06/25 18:10
43F：→ TonyQ: 这是重新开发新功能了. XD 06/25 18:10
44F：→ TonyQ: 另外重构不会碰到一万行还是一千行的问题,重构就是涵盖问题 06/25 18:11
45F：→ TonyQ: 一万行或一千行没有差别, 做法都是一样的. 06/25 18:11
做法一样, 时间跟规模不会一样, 这你认同吧
※ 编辑: EricTCartman (36.231.112.12 台湾), 06/25/2020 21:01:02
46F：→ viper9709: 推一楼 06/27 01:27