※ 引述《Ghamu (猫丸)》之铭言：
: 但事实上之前都没写测试了
: 你怎么证明他之前是对的呢?
这就是TAD, 一般做法是假设以前人做的是对的
拿以前的output当测资 避免以后的output跟预期结果不同
技术面的错误→没有防呆/没有释放资源/overflow/没有check
这应该不在讨论范围内, 也有客观标准
行为与逻辑的部分才是有争议的, 要嘛根本没规格只有口传
要嘛就是写的人弄拙成巧 刚好做对
所以在没有规格跟明确定义的状况下写测试 只是写的人自己觉得对而已
test code也是code 也一样要维护 也一样有可能会写错
: 所以我大多都直接给他改下去
: 反正重构后东西也比较清楚
: 即使有错 也比起虾鸡巴狗烂毛程式码好除错
每个人都觉得对方code烂 现在我都用: 我就烂 的心态来写
: 之前前辈都说会动的程式码不要去碰
: 然后就一球在那边
: 我说要改 他就说
: [啊你有写测试吗?]
: 开发时程又不允许
你没听出话中话 人家前辈是好心人
大家都写程式 又不是你最聪明 所有人都知道时程不允许
你改了code 出现一堆bug 锅在你头上
对方一方面也知道那是烂code不想明讲 搞不好写烂code的人还在公司
一方面也知道重构没有多少绩效 做不好还惹得一身臭 期望值低到爆表
人家处处为你着想 你何苦先入为主
要是我是你同事 一定默默地让你重构
: 就一球在那边越来越痛苦
: 会动的烂程式码越来越多
: 不知道大家怎么看
ptt都是菁英群
基本上大家写code都是clean code 还有落实unit test
要不是待在根本没有legacy code的新创公司
要嘛就是会把数以万计的legacy code补完unit test的楷模员工
你要是在的公司根本没有在写test
说明你公司太烂 八成没一个同事是乡民
建议你换好一点的公司 再上ptt跟大家讨论 比较有共同基准