我想补一个情境
当到新公司或转到新单位时
发现没有在做unit test
此时身经百战写过上千次unit test的你
会选择凭一己之力
引入测试框架及补完所有模组的单元测试吗？
当然这也代表那些高耦合的模组你要想办法拆分
其中改坏了算你的锅，改好没人在乎
而且高机率你得自己维护测试code
还是选择打不赢就加入？
我很好奇
大家可以分享一下吗
我自己是选择不改啦

什么叫做一己之力? 什么叫做自己选择? 请开会讨论你上面叫你改你就改, 叫你不要改就不用改

你想改本来就要知会主管不是吗？还是你当的RD没权力在软件品质上提意见？

所以团队如果不支持就不用改了如果团队支持, 那就不是你的锅, 也不会没人在乎

这种工作吃力不讨好，除非主管说你考绩会变好，不然就算了

是不是99%台湾的公司都不在意code quality?

这种层级的问题我都会议上报上去，主管决定要排谁来改。

没测试就是直接重写重写的时候顺便补 上面的人不支持你重写的话当然就不去动

就….默认的后续其实不会发生，想改一定是提出来讨论，讨论过了才能动工，那这时怎么可能都给一个人扛，要马趁改版时慢慢补，要马就是慢慢拆出来补，上司一定得跟进度，也不可能让人随意影响到实际运行的商品

你一个刚来的菜鸟什么都不知道，怎么可能做的出所有测试除非前人有留完整且正确的架构图给你，我是从未见过啦还有各种独门秘方藏在某人电脑里，通常都是主管

你什么都不知道要测啥 怎么写

没test的code会有spec给test用? 水星捞到鲸鱼机率高一点

一意孤行反而其他不会改UT的一直问你为什么code CI跑不过

他们不会问你，会直接跟上面说因为你的东西阻碍产出然后你就变成影响公司营收的罪人，KPI完蛋，信用扫地教科书上那些好棒棒的理想留着自己用就好，现实不是这样

unit test会牵扯到重构，绝不只是写unit test而已

独门秘方藏在电脑里XDDD

新开发的才会用，时间要用对地方，不要只是为了写而写

观察团队文化而定吧？！

Unit test 绝对要重构 除非原来的dependcies 早就弄好

当然不要写啊 淌混水干嘛？测试也是要维护的 没人写 后续也没人要维护 那测试很快变拉机等你离开该单位 你写的测试又变成别人的麻烦

看上面的老板会不会加钱，不然弄完被开除怎么办还是多写几个坑，让别人踩比较实在

想接这题问：如何能够提升高层对于 code quality 的重视度？每次碰到前人留下来的屎都很想砸电脑不弄了

去公司外面绕一圈看尽好扣烂扣，提升自己的耐受性然后释怀

可能发展如下，本来运作好好的系统，因为你补了测试找出潜在问题，另一个是你改坏了。前者可能没人在意，是后者那你麻烦很大。一是期待别人跟上你的成长，另是产生影响力，也许结果很像，但意义上完全不同。

正解：就把电脑砸了吧 就换工作 不然就自己创业高层老板会重视程式品质 也不用等到你来讲喇 哈

太年轻了啦，做的过程中谁有空告诉你一堆历史遗留问题的原因，做完了自己没 credit 反而帮到别人，出问题却又会变责任中心，帮这种的吃力不讨好的事谁爱做？更常见的高手齁，当然是做一页投影片上报高层说 legacy巴拉巴拉，新的方法可以解决问题，还可以怎样怎样更有梦想，说服高层给 resource 重新弄一套，斗斗老屁股爬上去当大王啊

能卖钱最重要，你在意的po或许根本没差

我现在走的就是一，很大的原因是因为我直接对到大主管，他也支持我这么做

主管没叫你做就不要做啊，改烂背锅，改好也没人感谢你