Rails Rails 每次升级都剥一层皮啊
从 5.0 升到 5.2， render :text redirect_to :back 都不能用了，改成了更“优雅”的方式。
Model.destroy_all(field: [condition]) 不能用了，改成了 Model.where(field: [condition]).destroy_all，这个改动我是支持的，本来就应该加 where，除了 where，任何方法后面都不应该进行过滤操作。希望后面的版本把 find_by 也去掉，改成 Model.where(field: [condition]).find，统一格式，这方面 python 和它的框架们都做得很好。
这样每次升级都带来一些小彩蛋，对玩来说很有趣，对真正的生产环境造成的伤害是灾难性的。直接报错的改动还好，网站跑不起来了，哪个功能不能用了，程序员会发现问题解决问题。
最可怕的是：一些改动不会报错，但会让业务逻辑发生变化，系统还在看上去还在平稳的运行，但是产生的业务数据已经错乱了，可能数十天甚至数月都发现不了。如果是一个电商系统甚至是一个银行系统，你品，你细品。
gaicitadie
回复
Basecamp 的代码测试比率是 0.8 左右（代码 10:测试 8），我的代码也差不多。重点业务多一下，例如订单处理，次要业务少一些，但也至少有一个测试。
hw676018683
回复
php 和 java 基本上不用考虑兼容问题，只要不是跨度特别大的版本，升就是了，唯一需要关心的就是升级后性能更好了还是更差了。当然，这个代价就是 php 再丑的命名格式，也只能一条道走到黑，改良不存在的。java 还好，一开始就考虑到了整体的规划，不像 php 一拍脑袋就命名一个内置函数。
而且 java 还是编译类型语言，方法被删掉或者改参数的话直接就能发现错的地方，而且一般也不删除代码都用 @Deprecated 注解标记该方法已不推荐使用在编译的时候也会有提示
希望后面的版本把 find_by 也去掉，改成 Model.where(field: [condition]).find
这个希望难以实现。find_by 是 rails 4 新增的，可以考虑降级到 rails 3
