瞎扯淡 Rails 除了开发速度,还能给公司带来什么?

rocLv · September 15, 2018 · Last by sefier replied at October 05, 2018 · 4999 hits

最近在 HN 上有一篇很火的文章,有兴趣的可以去看看。原文链接:Is Rails still relevant in 2018 ?

题记:最近因为组织Ruby Summit China 2018 大会的缘故,接触了一些之前一直在用 Rails 的公司的技术负责人(或 Leader,程序员),有几个比较大的公司或者说“我们已经转其他语言了”,或者说“我们正在转向其他语言”,然后我想结合我自己的实际经验,谈谈公司使用 Rails 的一些感受。

用或者不用 Rails,上面的那篇文章应该分析的非常详细,面面俱到了。

但是我想从经济的角度谈谈一些我的感受。

Rails 网页开发的生态经过很多年的发展,非常成熟

Rails 自从第一版发布到如今已经走过了快 14 个年头了,围绕着 Rails Web 开发有着许多不错的 Gem,这些 Gem 包让我们可以很快的搭建起来产品的原型。因为对其他语言的框架,了解比较少,至少在我浅尝辄止的过程中,我感觉到很少其他语言在 Web 开发库方面能和 Rails 的生态相比。

这点对公司来说,带来的经济价值就是减少了公司重新造轮子所带来的人力和资源上的消耗。

惯例优于配置,降低了优秀程序员的门槛

理论上来说,惯例优于配置,并不会真正降低了优秀程序员的门槛。知之而行和不知而行的差别是显而易见的。

但是,在大多数的情况下,只要我们遵循社区的最佳实践,相对来说比较容易写出较高质量的代码。

从经济的角度来说,我们有可能让初级的程序员,写出中级程序员以及高级程序员才能写出的代码。

原因显而易见,这些最佳实践,都是源于顶级程序员多年的经验总结。

前后端分离,无形中提高了对前端程序员的要求

我们在公司实践过一段时间前后端分离,后来还是放弃了。

放弃的原因很简单,因为我们的前端工程师,并不能够流畅的使用现代前端构建的工具。这些工具带来的效益比如自动 assets 压缩,缓存等等都对前端程序员有较高的要求。

现在一个能熟练掌握前端构建工具,如 Webpack 等,掌握 React/Vue 全生态的程序员,一定是一个相对高级的前端工程师了。

Rails 通过 Sprockets 实现了前端资源的自动压缩,使用 Turbolinks 优化了前端的加载速度,注意,这些几乎都是 Rails 自动完成的。

erb 模板文件,俄罗斯套娃式的缓存,对于有一定学习能力的前端工程师来说,掌握起来比 Redux 不知道要容易多少倍。

前后端分离,如果实施不当,很容易变成东施效颦。

乖乖的待在 Rails 的前端生态中,用户 Rails 的前端工具,依然可以满足现今大部分公司的业务需求。

前后端分离,与其说是公司的需要,可能更大程度上是程序员对于技术栈追求的需要。

以上三点,是我目前感受最深的几点,欢迎拍砖。

1.确实一些新语言的出现,对 Rails 造成了很大的冲击。但是软件开发是一个系统工程,应该从全局去衡量。没有人真的统计过开发相应的系统,整个公司的开销,我想一旦去统计,就会发现事实并不像想象那样。

2.惯例优于配置确实并不能降低优秀程序员的门槛,但是在实际上有助于初级程序员提高代码的质量。反过来,也会促进程序员的成长。

3.我这篇主要是从经济的角度去谈的,过高的开发门槛,必然会导致公司人力成本的提高。同样的效果,如果能让水平一般的人来实现,何乐而不为?主要是高级别的程序员非常难招,说百里挑一,一点也不过分。

主要还是语言的弱点。比如说 Rust 的三条安全、性能、并发。Ruby 只是在性能上改进,安全上弥补字符串改成不可改,也在探索类型系统。但是要与新语言全面竞争肯定是劣势。

Rust 的面向对象感觉比较折衷和可行,数据默认为只读,也没有继承,这样就杜绝了数据耦合。

老外博客分享的是 Elixir 可以省掉三分之一的烦恼,另外有公司定了目标五年之内 Elixir 进入前十名语言。而目前 Rust 排名快速上升到 31 位。

经济考虑是可以理解和必要的,我上次在网上遇到 dry 的负责人,他说目前还是 Ruby 为主,因为有前期投资,不排除逐步引入 Elxiir。

至于说人员,为什么不用质量换数量呢?当然人难找是个事实。

成本… 高工资的程序员薪水是看得见成本,低效程序员的成本是看不见的成本

就现在这个行情,使用 Rails 给公司节约出来的人力成本很快就会被额外的招聘成本所抵消掉吧。

Reply to adamshen

主要是 rails 难以招到人?

Reply to adamshen

社区的活跃离不开每个人的努力,这也是办 ruby 大会的意义

好酒也怕巷子深,各位 Rubyist 多做轮子,多向周围的人宣传,有能力的可以在高校办活动。

新出现的东西没看出来哪个解决了 Rails 没有解决或者解决的不足的问题。至于 react,vue,前后端分离,这些跟 rails 又不矛盾。

Reply to posee

是啊。

知名度其实很重要,大家认为学这个以后能够进大公司、赚大钱,才会有人学。多数人都是这样的,靠少数爱好者社区只能勉强维持,很难继续壮大。然后这种情况下能入坑的大多数是一些 geek,干了一段时间他觉得技术上没有新鲜感了,于是就会跑去折腾别的东西。大多数公司需要的是能花时间把公司的业务梳理得更清楚的码农,技术能力够用就可以了,太 geek 有些时候弊大于利。招几个新手来培养一下吧,也不简单。元编程、惯例优于配置等等,写起来是比较爽,但是维护起来就不是那么回事了。本来依靠静态分析或者在编译时就可以发现的问题,现在要依靠 CI,或者纯脑力去发现。一些静态语言,只要学会基本语法,自己去跟代码,最后总能找到问题点。普通的 Rails 新手,要是调用接口的结果和自己的认识不一致,就很难了,要成为即战力恐怕至少得三个月。种种原因都造成了 Rails 招工难的问题。

带来受不了委屈的,干不了脏活的,矫情的一逼的员工。

PHP 才是公司的最爱,连 PHP 这么丑陋的语言都能接受的程序员,什么活接受不了?

Rails 通过 Sprockets 实现了前端资源的自动压缩,使用 Turbolinks 优化了前端的加载速度,注意,这些几乎都是 Rails 自动完成的。

最主要的问题是,类似的方案,npm 那边可以拿出来 100 个。。。社区太兴旺了。。。小公司里挑一个就可以上手,大公司还可以反复造轮子刷 KPI。。。。。所以部门编制越来越大出路越来越广。。。。

rails 自身太优秀把自己的路走死了。。

14 Floor has deleted

说到底还是大前端对 Rails 的冲击,写接口的就好好写接口,前端构建基本的常识难道也成高级工程师了,组件化开发谁用谁知道,路由视图无需后端干预,把数据接口准备好就 OK,Rails 的确设计理念优秀,导致很多其它语言也都有相应的借鉴的框架,但是越来越多的人已经不喜欢全栈开发框架了,而是需要一个纯接口的开发框架而已,当然还有一部分原因是老生常谈的性能问题。

我觉得 rails 性能还可以呀。又不是每个程序都会存在很高的并发问题。。做 web 有页面缓存,还有 controller 缓存,性能不是根本问题,

Reply to bighuzi

这个是相比较而言的

Reply to adamshen

现在的 nodejs 是否对 ror 构成挑战了呢?

Reply to gaicitadie

PHP 不丑陋吧

Reply to posee

不是很了解 nodejs,个人觉得 Rails 的衰弱并不是因为其他更优秀竞品的出现,而是和它自身的特点以及时代发展有关。不过话说回来,要是现在让我起手一个 web 项目,第一选择还是 Rails,最大的原因当然是因为——我只会这个。

Reply to adamshen

rails 衰弱了么?

纯接口开发框架,ruby 社区用的主要是哪个?

Reply to posee

Rails 刚出来的时候,可以说一家独大,独特的 MVC 框架,在哪个没有框架的年代无异于一颗耀眼的明星

如今各种框架纷呈,其他语言的程序员也有了更多的选择

所以从这种角度上来说,Rails 是衰弱了,不过 Rails 还是 Rails,只是大家选择更多而已

Reply to rocLv

你现在写 rails 是否也用到 node 工具了呢?

Reply to posee

会的

Reply to rocLv

打包用的主要还是 asset pipeline?

Reply to gaicitadie

哪些算脏活?

Reply to posee

对于小团队来说建议使用 asset pipeline,因为对前端要求不高 对于不差钱,不差人才的,想怎么样就怎么样吧 技术只是个工具,需要各方面来权衡

Reply to rocLv

对于多大的项目,ruby 性能才会成为问题呢?

Reply to posee

性能的问题一直存在,

越大的项目,性能问题会越突出

Reply to rocLv

很大的项目,python 怎么样?性能会比 ruby 好?

Reply to posee

python 也不怎么样

Reply to rocLv

难道你想说 java 么:(

每月日常问题。相比于 Ruby,感觉 Python 够流行了吧?然而 Python Web 找工作好像也不咋地

Reply to posee

编译型语言普遍比解释型的语言性能高

Reply to fredwu

怎么评价代码质量?

Reply to fredwu

不堪入目,是指代码难以读懂么:(

Reply to fredwu

你的 Elixir 什么应用场景?

Reply to gzhi1992

应该是 active job, active storage 吧

You need to Sign in before reply, if you don't have an account, please Sign up first.