Rails Rails 每次升级都剥一层皮啊

gaicitadie · 2020年06月25日 · 最后由 huacnlee 回复于 2020年06月30日 · 3035 次阅读

从 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 和它的框架们都做得很好。

这样每次升级都带来一些小彩蛋,对玩来说很有趣,对真正的生产环境造成的伤害是灾难性的。直接报错的改动还好,网站跑不起来了,哪个功能不能用了,程序员会发现问题解决问题。

最可怕的是:一些改动不会报错,但会让业务逻辑发生变化,系统还在看上去还在平稳的运行,但是产生的业务数据已经错乱了,可能数十天甚至数月都发现不了。如果是一个电商系统甚至是一个银行系统,你品,你细品。

不会有人不写测试吧,不会吧不会吧?

Rei #2 回复

总有测试覆盖不到的地方,如果把测试的覆盖率弄的高一点,工作量可能就比程序本身还大了

gaicitadie #3 回复

Basecamp 的代码测试比率是 0.8 左右(代码 10:测试 8),我的代码也差不多。重点业务多一下,例如订单处理,次要业务少一些,但也至少有一个测试。

测试代码的 destroy_all 也要改成 where.destroy_all

不是有 ChangeLog 吗,难道升级成功的标准就是能启动服务器吗

hw676018683 #6 回复

php 和 java 基本上不用考虑兼容问题,只要不是跨度特别大的版本,升就是了,唯一需要关心的就是升级后性能更好了还是更差了。当然,这个代价就是 php 再丑的命名格式,也只能一条道走到黑,改良不存在的。java 还好,一开始就考虑到了整体的规划,不像 php 一拍脑袋就命名一个内置函数。

而且 java 还是编译类型语言,方法被删掉或者改参数的话直接就能发现错的地方,而且一般也不删除代码都用 @Deprecated 注解标记该方法已不推荐使用在编译的时候也会有提示

这才哪到哪,比起搞前端的幸福多了呀,几乎整个 api 都给你换掉好不好~

希望后面的版本把 find_by 也去掉,改成 Model.where(field: [condition]).find

这个希望难以实现。find_by 是 rails 4 新增的,可以考虑降级到 rails 3

比前端好多了 前端一升级,全部要推翻了重写。语言都给你换了

对着 Changelog 改,掌握好规律,其实很简单的

需要 登录 后方可回复, 如果你还没有账号请 注册新账号