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

rocLv · 2018年09月15日 · 最后由 sefier 回复于 2018年10月05日 · 1774 次阅读

最近在 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 的前端工具,依然可以满足现今大部分公司的业务需求。

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

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

共收到 39 条回复

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

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

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

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

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

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

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

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

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

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

adamshen 回复

主要是rails难以招到人?

adamshen 回复

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

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

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

posee 回复

是啊。

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

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

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

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

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

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

14楼 已删除

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

hxh1246996371 回复

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

bighuzi 回复

这个是相比较而言的

adamshen 回复

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

gaicitadie 回复

PHP不丑陋吧

posee 回复

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

adamshen 回复

rails衰弱了么?

hxh1246996371 回复

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

posee 回复

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

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

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

rocLv 回复

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

posee 回复

会的

rocLv 回复

打包用的主要还是asset pipeline?

gaicitadie 回复

哪些算脏活?

posee 回复

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

rocLv 回复

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

posee 回复

性能的问题一直存在,

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

rocLv 回复

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

posee 回复

python也不怎么样

rocLv 回复

难道你想说java么:(

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

入行十多年,接触 Ruby/Rails 近十年,接触 Elixir 两三年,从带领小团队到带领 20 多人的团队后…… 小小的领悟是,对于大部分 CRUD 类的项目,比较笼统的个人看法:

当一个团队中大部分都是经验老道的成员的话,我还是会选择 Rails (或是至少选择 Ruby)。

当一个团队中大部分是入行不久的新人时,我会选择 Elixir 或其他 FP。

我个人接触过的不论是开源项目还是闭源项目,采用 Rails 的代码质量普遍较差(有些甚至是不堪入目)。:(

posee 回复

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

fredwu 回复

怎么评价代码质量?

fredwu 回复

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

fredwu 回复

你的Elixir什么应用场景?

gzhi1992 回复

应该是active job, active storage吧

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