从成本角度看软件的负优化

我认为负优化是一个带有目的的主动行为，目的是获取更大收益，反之则不算。比如淘宝更新变卡变难用，用户抱怨负优化，但是用户体验变差对淘宝没有收益，所以这只是懒得优化 _(`」 ∠)

也不一定，我觉得如果出于商业原因，比如苹果税，宣传，做负优化是可能的，比如原神崩铁的安卓手柄支持

工厂里有项工作叫持续改善
当年做的工时测试单位都已经是毫秒级

遇到一些烂 erp 的操作问题，开发公司总是会有种种理由拒绝改善，也许是钱不到位，更好的用户体验对他们也没有工时损耗。更大可能是牵一发动全身，懒得改。没钱没动力。

这里根本的矛盾是用户感知到“新的更新出现了 regression”。只是用户不会这么描述问题，也不知道“用户体验变差对淘宝没有收益，所以这只是懒得优化”。所以就用“负优化”这个词来指代这种现象。

在用户的认知里，新的版本应该在最终体验上“应该”是“正优化”的。那么现状是开发新版本肯定有一定的工作量，就连用户更新都要耗费网络流量、存储空间和 CPU 时间，最后唯一的感知是 regression ，那么你们这些工作量干啥去了呢，当然是做了“负优化”。
你会说我做了新功能啊。可是根据二八定律，大多数新功能用户感知不到。安全更新更是如此。

争论“负优化”这个说法的具体含义，意义有限，这个词只是一个缩写罢了。你可以给用户灌输“用户体验变差对淘宝没有收益，所以这只是懒得优化”，但是你没有解决用户感知到的问题，只会起“试图教育用户”的“负效果”罢了。

"负优化是一个带有目的的主动行为，目的是获取更大收益" 你能举个例子吗

没搞懂“负优化”的概念，尤其是这个说法：“但是用户体验变差对淘宝没有收益”，不应该这么讲么：“但是用户体验变好（差->好）对淘宝没有收益”。

优化一般是中后期才做的事情，前期不要投入精力去优化，因为前期软件变化会比较大，优化后马上有变化了等于白优化了。到了该优化的时候而不做优化，这种可能性比较大：

前期设计失误，做到后面软件长残了。改进需要大改甚至推倒重来，导致没法优化，或者是优化等同于重做。这种（软件工程上的）原因估计国内挺多的，以至于维持运营就行，体验、故障等问题交给客服处理。

一次好的重构是结果明确、过程清晰、收益显著的（为未来开辟了新的可能性），它会让所有人开心。你可以列出三个各自独立的重构计划（在三处进行重构），按照收益排序并择优挑出收益显著的那一个来进行。