楼主:
Ghamu (猫丸)
2020-07-02 02:48:37想想这应该算是一种迷思吧
理论上是这样没错
但事实上之前都没写测试了
你怎么证明他之前是对的呢?
所以我大多都直接给他改下去
反正重构后东西也比较清楚
即使有错 也比起虾鸡巴狗烂毛程式码好除错
之前前辈都说会动的程式码不要去碰
然后就一球在那边
我说要改 他就说
[啊你有写测试吗?]
开发时程又不允许
就一球在那边越来越痛苦
会动的烂程式码越来越多
不知道大家怎么看
作者:
ousapas (komica123)
2020-07-02 04:01:00如果是老程式码可以把手测流程自动化成functional test不用执著于一定要写unit test如此一来不须要100% coverage也能安心重构
作者: keyboard56 (奇伯) 2020-07-02 07:25:00
证明他是对的这件事因为在正式环境运行一段时间了没有使用者反应问题，基本上就是证明他没错
作者:
NDark (溺于黑暗)
2020-07-02 07:29:00不是证明是对的。是要证明改前后的输出是一样的。很多情况是函式Ａ写错除二 Ｂ只好跟着错乘二 补回来这时候只重构Ａ或是只重构Ｂ都不能把错误"改正"因为无法确定是不是只有Ｂ会吃到Ａ的结果。
作者: keyboard56 (奇伯) 2020-07-02 07:32:00
全新的需求就可以跟使用者来回确认。重构跟开发全新需求是两件事，你没办法在跟使用者去确认，所以你只能自己确认
作者:
alihue (wanda wanda)
2020-07-02 07:53:00好好写不行吗
好险你没改到出包 哪天出包你就知道为啥前辈都放著不管了 嘻嘻
公司现在就能赚钱，为什么要另外花成本重构？测试只是为了得出相同结果的手段，你的目的是想重构而不是减少测试。你要提出重构的效益说服pm、老板，而不是前辈，老板觉得重构好就会做了。
作者:
yyhsiu (hsiu)
2020-07-02 08:12:00觉得楼上说的非常中肯，各种教条要配合想要的结果跟手段盲从跟随便说教条是迷思，而不看自己的情况、背后的理由都不太好
作者: hidog (.....) 2020-07-02 08:18:00
理性是要有测试再重构，但还是要考虑实务问题理想 打错字
作者:
Csongs (西歌)
2020-07-02 09:14:00估开发时间就是要把测试考虑进去啊
作者:
allenxxx (fufuxxx)
2020-07-02 09:31:00你如果在开发团队中够力,可以去做,不然最好先找下一家有没有想过你改了人家东西,原负责人拒绝维护谁会死你可以接下他的工作吗?这行乱动不属于自己的东西来配合自己想法,是大忌!
作者:
umum29 (....)
2020-07-02 09:38:00团队若实行code review和ticket system 哪有不能改的程式我待过工厂IT也待过agile开发 制造业IT很符合楼上的说法
作者:
a926 (Aaron)
2020-07-02 10:36:00这是在钓鱼？
作者:
Masakiad (Masaki)
2020-07-02 11:10:00程式对不对跟spec上怎么定义有关，怎么会跟有没有测试有关？一开始的核心概念没搞懂你才会问这样的问题
说的很对，反正绩效算你的，技术债上门时大概也升官跳槽了
作者:
brucetu (sec)
2020-07-02 12:39:00反正改坏了出包你负全责不要推托说原本的code很烂那你爱怎么改都可以
写测试也要懂以前的逻辑脉络，但会重构就是以前的程式混杂一起到最后大家都不想补技术债，只想乱写，然后bugfix在丢给菜鸟乱补
作者:
Csongs (西歌)
2020-07-02 12:52:00真的很少接到舒服的code
把这时间省下来 刷leetcode、练英文比较实在
作者:
deray (Deray)
2020-07-02 13:36:00工啥小啦干
作者:
Masakiad (Masaki)
2020-07-02 13:56:00推文看下来觉得这些系统真的很堪忧阿
作者:
cphe (魔鬼藏在垃圾筒里)
2020-07-02 14:00:00这老议题了...
作者:
NTULioner (LionsHeart)
2020-07-02 14:20:00工作不要出包最重要改好 上面不觉得有功 改烂马上变战犯
就是遇过有人说要重构 然后也重构了 结果一堆bug又不修 然后只好等下一个人来重构loop?
作者:
Masakiad (Masaki)
2020-07-02 15:01:00楼上，所以才要先写测试后才重构，然后重构目标跟debug完全不同，怎么回有bug结果又重构这种操作？
作者:
alihue (wanda wanda)
2020-07-02 15:24:00其实写测试可以让重构更快
作者:
luke72 (ccc)
2020-07-02 15:31:00菜鸟 程式出包责任是你扛还是前辈扛 别人扛责你干嘛管很多东西是有历史因素的 没搞清楚就乱重构容易出事
重构者不继续维护 然后接任者有起了重构的心 loop就出现了*又现实中遇过因为架构上限制包含整个协议重构 结果重构后的东西太多问题不能用 省下重构时间想个新产品来玩说不定还比较好
作者:
Masakiad (Masaki)
2020-07-02 16:55:00每次都要把什么担责任加进来讨论，重点就算有授权这边也一堆人搞不懂怎么重构
作者:
sharku (明珠求瑕)
2020-07-02 17:10:00烂 code 是造成 delay 跟 online issue 的元凶
作者:
ssccg (23)
2020-07-02 17:22:00会动不就是对的? 不然还能叫会动吗?不是重构要写测试，是有测试比较好重构，没测试你重构完了还不是要手动测好测满?
作者:
allenxxx (fufuxxx)
2020-07-02 17:44:00测试之前也要先理解业务流吧,很多很奇特的你认为的狗屁逻辑其实都是有历史典故而且不得不做的,当特例变成客户常规,你要不要配合?那你看不懂自作聪明修了...保重
作者:
vencil (vencs)
2020-07-02 18:18:00其实是本来就该测试了 不是等到重构才在想
作者: mpjp (mpjp) 2020-07-02 18:30:00
你又怎么知道你写的是对的XD
作者:
hichcock (快乐一整年 ^^~~~)
2020-07-02 18:47:00先下手再说
作者:
xephon 2020-07-02 19:12:00改成你以为的正确可能会出事
作者:
Ekmund (是一只小叔)
2020-07-02 19:48:00后来看前辈的操作是，把需求摸透，甚至说服上面的需求范围后，在还没被授意前就硬干前几段提初步成果再说。反正头洗下去结果好看，顶头多会给你试，要缩成本也不高
那是你的前辈credit够多可以烧，一般人先斩后奏的下场都不是太好
作者: t64141 (榕树) 2020-07-02 21:03:00
我的操作跟E大前辈差不多，不过是先在本机做实验样品，觉得可行再去说服上面后才会真的正式做/commit或是趁著需求变更顺便做效果也不错
小范围重构免强睁一只眼闭一只眼说肉眼可判断不会出错大范围重构还不写测试是想?
作者:
v7q4 ((．)(．)乳剑双修 -|＝＞)
2020-07-02 23:08:00一池猪屎，好不容易经过时间的累积，终于表面干掉不会臭，就没必要去搅动它了！
楼主:
Ghamu (猫丸)
2020-07-02 23:49:00目前手上的程式连文件spec 都没有 所以我随便改没差
作者:
Nonegrame (程式写得好，好人做到老)
2020-07-03 00:24:00上班没空写测试 下班写啊 就这么简单
作者: jasonwung (路人JJ) 2020-07-03 00:32:00
你终究要作测试验证，何不一开始就写测试
作者:
siriusu (かがみは俺の嫁。)
2020-07-03 08:15:00大家讲的差不多了，测试就是帮助确认品质，而已经上线过的系统某种程度就是就过验证的；所以不要偏离原本的行为是有价值的，就看这个价值对你来说有多少（系统多少人使用、是不是完全不能出错的系统）
作者:
bnd0327 (阿噗噗)
2020-07-03 10:27:00直接改下去，万一发现改不好不是进退两难?
作者:
meowyih (meowyih)
2020-07-03 20:51:00就算不说测试，你怎么证明你写的会比原来的好？你觉得你写的比较好debug那只是因为是自己写的啊，你走人后别人也会这么认为吗？颗颗
作者:
Masakiad (Masaki)
2020-07-03 21:36:00会啊，之后还请我做consultant
作者:
APTON (玮玮)
2020-07-04 10:47:00比较残酷的是....说没时间写测试的，实际给了时间还是写不出来QQ
还没有真的user勇敢改不要怕 有真的user就问问看pm
作者: daddy29 (愿上帝与你同在) 2020-07-04 11:42:00
妳问题比较大 开发时程不够两件事 1.能力不足 2.看不清等级在哪边 还想要重构
作者: lukelove (午睡) 2020-07-04 12:03:00
嘻嘻 你确定你改完会比较好维护? 一堆越构越烂逻辑越复杂的例子
你的实力没被认同才会被这样说,只能靠你自己証明如果你很强,怎么做都是可行的
要了解架构才能写出好的，有意义的测项吧没有了解，你能确定你的测法是正确的吗
作者:
mathrew (Joey)
2020-07-05 12:18:00因为你只是改成你认为正确的，事实上现在运作没出大问题也许你写出来的只是对你来说 你比较好debug因为是你写的，所以你会知道问题在哪，但对别人来说不是
楼主:
Ghamu (猫丸)
2020-07-06 01:27:00其实应该说清楚一点 本来程式一大球 好几行 分崩离析 拆成小分小分 即使有错也比一整包天书好解决吧
啊人家就会动没出错 哪会比你没写测试重构出错差?烂code至少用能动说服大家它能用了 你连测试都不想写要怎么说服别人重构会比较好?
作者:
rodion (r-kan/reminder)
2020-07-06 17:20:00原PO似乎弄错测试程式的目的了? 测试是为了确保行为一致输出正确与否 不是测试程式应该着力的点