作者Ghamu (猫丸)
看板Soft_Job
标题[讨论] 重构之前要写测试 不然不要重构
时间Thu Jul 2 02:48:37 2020
想想这应该算是一种迷思吧
理论上是这样没错
但事实上之前都没写测试了
你怎麽证明他之前是对的呢?
所以我大多都直接给他改下去
反正重构後东西也比较清楚
即使有错 也比起虾鸡巴狗烂毛程式码好除错
之前前辈都说会动的程式码不要去碰
然後就一球在那边
我说要改 他就说
[啊你有写测试吗?]
开发时程又不允许
就一球在那边越来越痛苦
会动的烂程式码越来越多
不知道大家怎麽看
-----
Sent from JPTT on my Sony F5321.
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 101.15.130.230 (台湾)
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1593629319.A.05A.html
※ 编辑: Ghamu (101.15.130.230 台湾), 07/02/2020 02:52:31
1F：推 ousapas: 如果是老程式码可以把手测流程自动化成functional test 07/02 04:01
2F：→ ousapas: 不用执着於一定要写unit test 07/02 04:01
3F：→ ousapas: 如此一来不须要100% coverage也能安心重构 07/02 04:02
4F：推 keyboard56: 证明他是对的这件事因为在正式环境运行一段时间了没 07/02 07:25
5F：→ keyboard56: 有使用者反应问题，基本上就是证明他没错 07/02 07:25
6F：嘘 chchang0820: 你怎麽证明他之前写的是对的?是不是连需求都不清楚 07/02 07:26
7F：推 NDark: 不是证明是对的。是要证明改前後的输出是一样的。 07/02 07:29
8F：→ NDark: 很多情况是函式Ａ写错除二 Ｂ只好跟着错乘二 补回来 07/02 07:30
9F：→ NDark: 这时候只重构Ａ或是只重构Ｂ都不能把错误"改正" 07/02 07:31
10F：→ NDark: 因为无法确定是不是只有Ｂ会吃到Ａ的结果。 07/02 07:31
11F：→ keyboard56: 全新的需求就可以跟使用者来回确认。重构跟开发全新 07/02 07:32
12F：→ keyboard56: 需求是两件事，你没办法在跟使用者去确认，所以你只 07/02 07:32
13F：→ keyboard56: 能自己确认 07/02 07:32
14F：嘘 alihue: 好好写不行吗 07/02 07:53
15F：推 GinginDenSha: 好险你没改到出包 哪天出包你就知道为啥前辈都放着 07/02 08:04
16F：→ GinginDenSha: 不管了 嘻嘻 07/02 08:04
17F：推 shingatter: 公司现在就能赚钱，为什麽要另外花成本重构？ 07/02 08:11
18F：→ shingatter: 测试只是为了得出相同结果的手段，你的目的是想重构 07/02 08:11
19F：→ shingatter: 而不是减少测试。 07/02 08:11
20F：→ shingatter: 你要提出重构的效益说服pm、老板，而不是前辈，老板 07/02 08:11
21F：→ shingatter: 觉得重构好就会做了。 07/02 08:11
22F：推 yyhsiu: 觉得楼上说的非常中肯，各种教条要配合想要的结果跟手段 07/02 08:12
23F：→ yyhsiu: 盲从跟随便说教条是迷思，而不看自己的情况、背後的理由 07/02 08:13
24F：→ yyhsiu: 都不太好 07/02 08:13
25F：推 hidog: 理性是要有测试再重构，但还是要考虑实务问题 07/02 08:18
26F：→ hidog: 理想 打错字 07/02 08:19
27F：→ x000032001: 去找RD lead决斗阿 pm懂个小喔 07/02 08:28
28F：→ Murasaki0110: 你要拿你的绩效赌谁管得着 07/02 08:50
29F：推 vi000246: 抱着离职的决心就可以唷 07/02 09:12
30F：推 Csongs: 估开发时间就是要把测试考虑进去啊 07/02 09:14
31F：→ allenxxx: 你如果在开发团队中够力,可以去做,不然最好先找下一家 07/02 09:31
32F：→ allenxxx: 有没有想过你改了人家东西,原负责人拒绝维护谁会死 07/02 09:32
33F：→ allenxxx: 你可以接下他的工作吗? 07/02 09:32
34F：→ allenxxx: 这行乱动不属於自己的东西来配合自己想法,是大忌! 07/02 09:34
35F：→ umum29: 团队若实行code review和ticket system 哪有不能改的程式 07/02 09:38
36F：→ umum29: 我待过工厂IT也待过agile开发 制造业IT很符合楼上的说法 07/02 09:39
37F：嘘 DCTmaybe: 他之前写的程式还有在帮公司赚钱就是对的 07/02 10:34
38F：推 a926: 这是在钓鱼？ 07/02 10:36
39F：→ Masakiad: 程式对不对跟spec上怎麽定义有关，怎麽会跟有没有测试 07/02 11:10
40F：→ Masakiad: 有关？一开始的核心概念没搞懂你才会问这样的问题 07/02 11:10
41F：推 strike5566: 说的很对，反正绩效算你的，技术债上门时大概也升官 07/02 12:09
42F：→ strike5566: 跳槽了 07/02 12:09
43F：推 brucetu: 反正改坏了出包你负全责不要推托说原本的code很烂 07/02 12:39
44F：→ brucetu: 那你爱怎麽改都可以 07/02 12:39
45F：→ leo5916267: 写测试也要懂以前的逻辑脉络，但会重构就是以前的程 07/02 12:50
46F：→ leo5916267: 式混杂一起 07/02 12:50
47F：→ leo5916267: 到最後大家都不想补技术债，只想乱写，然後bugfix在 07/02 12:51
48F：→ leo5916267: 丢给菜鸟乱补 07/02 12:51
49F：推 Csongs: 真的很少接到舒服的code 07/02 12:52
50F：推 sniper2824: 你考机想吃饼我没意见啊 07/02 12:59
51F：推 king22649: 把这时间省下来 刷leetcode、练英文比较实在 07/02 13:08
52F：→ deray: 工啥小啦干 07/02 13:36
53F：推 Masakiad: 推文看下来觉得这些系统真的很堪忧阿 07/02 13:56
54F：→ cphe: 这老议题了... 07/02 14:00
55F：→ NTULioner: 工作不要出包最重要 07/02 14:20
56F：→ NTULioner: 改好 上面不觉得有功 改烂马上变战犯 07/02 14:21
57F：嘘 annheilong: 怎麽证明之前的对不对 不就是写测试去验证吗... 07/02 14:23
58F：→ shooter555: 就是遇过有人说要重构 然後也重构了 结果一堆bug又不 07/02 14:33
59F：→ shooter555: 修 然後只好等下一个人来重构loop? 07/02 14:33
60F：→ Masakiad: 楼上，所以才要先写测试後才重构，然後重构目标跟debug 07/02 15:01
61F：→ Masakiad: 完全不同，怎麽回有bug结果又重构这种操作？ 07/02 15:01
62F：嘘 as23041248: 时程都不允许还重构0.0 07/02 15:04
63F：嘘 alihue: 其实写测试可以让重构更快 07/02 15:24
64F：推 luke72: 菜鸟 程式出包责任是你扛还是前辈扛 别人扛责你干嘛管 07/02 15:31
65F：→ luke72: 很多东西是有历史因素的 没搞清楚就乱重构容易出事 07/02 15:32
66F：→ shooter555: 重构者不继续维护 然後接任者有起了重构的心 loop就出 07/02 15:34
67F：→ shooter555: 现了 07/02 15:35
68F：→ shooter555: *又 07/02 15:35
69F：→ shooter555: 现实中遇过因为架构上限制包含整个协议重构 结果重构 07/02 15:37
70F：→ shooter555: 後的东西太多问题不能用 省下重构时间想个新产品来玩 07/02 15:40
71F：→ shooter555: 说不定还比较好 07/02 15:40
72F：→ Darkword1987: 要改可以 出错你扛 本来就是这样了啊 07/02 16:31
73F：→ Masakiad: 每次都要把什麽担责任加进来讨论，重点就算有授权这边也 07/02 16:55
74F：→ Masakiad: 一堆人搞不懂怎麽重构 07/02 16:55
75F：推 sharku: 烂 code 是造成 delay 跟 online issue 的元凶 07/02 17:10
76F：→ ssccg: 会动不就是对的? 不然还能叫会动吗? 07/02 17:22
77F：→ ssccg: 不是重构要写测试，是有测试比较好重构，没测试你重构完了 07/02 17:25
78F：→ ssccg: 还不是要手动测好测满? 07/02 17:26
79F：→ allenxxx: 测试之前也要先理解业务流吧,很多很奇特的你认为的狗屁 07/02 17:44
80F：→ allenxxx: 逻辑其实都是有历史典故而且不得不做的,当特例变成客户 07/02 17:45
81F：→ allenxxx: 常规,你要不要配合?那你看不懂自作聪明修了...保重 07/02 17:46
82F：→ bheegrl: 有些逻辑写错的改成对的是会出事的== 07/02 17:48
83F：推 vencil: 其实是本来就该测试了 不是等到重构才在想 07/02 18:18
84F：推 mpjp: 你又怎麽知道你写的是对的XD 07/02 18:30
85F：推 hichcock: 先下手再说 07/02 18:47
86F：嘘 xephon: 改成你以为的正确可能会出事 07/02 19:12
87F：推 Ekmund: 後来看前辈的操作是，把需求摸透，甚至说服上面的需求范 07/02 19:48
88F：→ Ekmund: 围後，在还没被授意前就硬干前几段提初步成果再说。 07/02 19:48
89F：→ Ekmund: 反正头洗下去结果好看，顶头多会给你试，要缩成本也不高 07/02 19:50
90F：→ foreverk: 那是你的前辈credit够多可以烧，一般人先斩後奏的下场 07/02 19:52
91F：→ foreverk: 都不是太好 07/02 19:52
92F：推 devilkool: 推Masa大 07/02 21:03
93F：推 t64141: 我的操作跟E大前辈差不多，不过是先在本机做实验样品，觉 07/02 21:03
94F：→ t64141: 得可行再去说服上面後才会真的正式做/commit 07/02 21:03
95F：→ t64141: 或是趁着需求变更顺便做效果也不错 07/02 21:11
96F：→ GoodFriday: 小范围重构免强睁一只眼闭一只眼说肉眼可判断不会出错 07/02 22:50
97F：→ GoodFriday: 大范围重构还不写测试是想? 07/02 22:51
98F：推 clamperni: 可怜哪 还在重构 07/02 22:54
99F：→ v7q4: 一池猪屎，好不容易经过时间的累积，终於表面乾掉不会臭，就 07/02 23:08
100F：→ v7q4: 没必要去搅动它了！ 07/02 23:08
101F：→ Ghamu: 目前手上的程式连文件spec 都没有 所以我随便改没差 07/02 23:49
102F：推 Nonegrame: 上班没空写测试 下班写啊 就这麽简单 07/03 00:24
103F：推 jasonwung: 你终究要作测试验证，何不一开始就写测试 07/03 00:32
104F：→ siriusu: 大家讲的差不多了，测试就是帮助确认品质，而已经上线过 07/03 08:15
105F：→ siriusu: 的系统某种程度就是就过验证的；所以不要偏离原本的行为 07/03 08:15
106F：→ siriusu: 是有价值的，就看这个价值对你来说有多少（系统多少人使 07/03 08:15
107F：→ siriusu: 用、是不是完全不能出错的系统） 07/03 08:15
108F：推 bnd0327: 直接改下去，万一发现改不好不是进退两难? 07/03 10:27
109F：嘘 InvincibleK: 长官没说改,就别动嘿 07/03 15:06
110F：→ meowyih: 就算不说测试，你怎麽证明你写的会比原来的好？你觉得你 07/03 20:51
111F：→ meowyih: 写的比较好debug那只是因为是自己写的啊，你走人後别人也 07/03 20:51
112F：→ meowyih: 会这麽认为吗？颗颗 07/03 20:51
113F：→ Masakiad: 会啊，之後还请我做consultant 07/03 21:36
114F：推 APTON: 比较残酷的是....说没时间写测试的，实际给了时间还是写不 07/04 10:47
115F：→ APTON: 出来QQ 07/04 10:47
116F：推 play1921: 还没有真的user勇敢改不要怕 有真的user就问问看pm 07/04 11:19
117F：嘘 daddy29: 你问题比较大 开发时程不够两件事 1.能力不足 2.看不清 07/04 11:42
118F：→ daddy29: 等级在哪边 还想要重构 07/04 11:42
119F：推 lukelove: 嘻嘻 你确定你改完会比较好维护? 一堆越构越烂逻辑越复 07/04 12:03
120F：→ lukelove: 杂的例子 07/04 12:03
121F：推 stupid0319: 你的实力没被认同才会被这样说,只能靠你自己证明 07/04 16:23
122F：→ stupid0319: 如果你很强,怎麽做都是可行的 07/04 16:24
123F：→ panbanana: 要了解架构才能写出好的，有意义的测项吧 07/04 17:22
124F：→ panbanana: 没有了解，你能确定你的测法是正确的吗 07/04 17:23
125F：推 mathrew: 因为你只是改成你认为正确的，事实上现在运作没出大问题 07/05 12:18
126F：→ mathrew: 也许你写出来的只是对你来说 你比较好debug 07/05 12:20
127F：→ mathrew: 因为是你写的，所以你会知道问题在哪，但对别人来说不是 07/05 12:20
128F：→ Ghamu: 其实应该说清楚一点 本来程式一大球 好几行 分崩离析 拆成 07/06 01:27
129F：→ Ghamu: 小分小分 即使有错也比一整包天书好解决吧 07/06 01:27
130F：推 highwayshih: 啊人家就会动没出错 哪会比你没写测试重构出错差? 07/06 07:25
131F：推 highwayshih: 烂code至少用能动说服大家它能用了 你连测试都不想写 07/06 07:29
132F：→ highwayshih: 要怎麽说服别人重构会比较好? 07/06 07:29
133F：→ rodion: 原PO似乎弄错测试程式的目的了? 测试是为了确保行为一致 07/06 17:20
134F：→ rodion: 输出正确与否 不是测试程式应该着力的点 07/06 17:21