For RubyChina's Rubyist, 是时候为 Rails 圈子打打气, Ruby 圈子创新能力依然在, Rails 活力依旧.
本文成因
最近朋友中加入了不少对技术不十分了解的朋友, 我希望能够简单有效回复他们 Rails 是干什么的.
是时候抬头看看整个 web 技术圈子发展的情况, 总结一下, 也顺带打消一些客户对于采用 Rails 的顾虑.
Rails 的起源
Rails 全称为 Ruby on Rails, 是基于 Ruby 编程语言 ( 一种通用的动态编程语言 ) 的 Web 全栈开发框架. 可以类比于 j2ee( 基于 java ), 类比 Symfony( 基于 php ), 类比 Django ( 基于 Python ).
Rails 起源只是一次无心的尝试, DHH( Rails 创始人 ) 在开发一个任务管理系统 ( basecamp ) 的时候, 感觉 php 写网站太磋了 ( 写过 Rails 的话, 你懂的 ), 就在 2003 年时候随带开发了 Rails.
之后, 05 年 12 月 Rails 1.0 发布后, 成为年度最佳 web 框架.
06 年, 由于 Rails 的大获成功, Ruby 从一个默默无闻的语言, 成长为在 TIOBE 统计用户使用量排名第十的语言.
之后, 中国国内开始后知后觉, 第一批创业者像 ITeye 的 robbin 开始使用 Ruby on Rails 作为自己的核心技术竞争优势.
这几年, Ruby 越来越成熟, 社区也越来越强大, Rails 在经历了 07-08 年的小低峰后, 在 09 年之后到 2015 年的今日, 又开始大发光彩.
越来越多的创业公司采用了 Rails
在国外, 一大批的创业公司采用 Rails 作为核心技术栈.
广为人知的:
-
Twitter ( 推特: https://twitter.com )
Twitter 从 06 年起便开始将其核心构建在 Rails 之上, 之后发展超过 5 年, 在 11 年才逐步将其搜索业务与消息队列从 Ruby 分别切换到 Java 与 Scala 上.
随后 12 年之后, 技术栈开始慢慢地多元化, 并开源了前端框架 Bootstrap( 没错, 就是大名鼎鼎的它 )
-
Github ( 找程序员哪里去, Github 等着你: https://github.com )
Github 是程序员事实的社交圈子, 它从 09 年开始起家, 一直构建于 Rails 技术栈之上. 经历过防火长城的恶意攻击, 却仍然坚挺. 详见: 乌云分析
只要有良好的横向扩展能力, Rails 的伸缩性也十分给力.
-
Kickstarter( https://kickstarter.com )
Kickstarter 是全球最著名的众筹平台, 09 年创建, 目前每天的访问量十分巨大, 其核心构建于 Rails.
只是找一些知名的案例, 大家肯定不满意, 别的平台与框架下也有不少案例, 对吧. 但接下来就有意思了, 越来越多的创业团队开始在使用 Rails.
比如最近的
-
producthunt ( 一个发现新产品的平台, 国内有很多赝品了: http://www.producthunt.com/ )
基于 Rails 构建, 据说, 只花了几天就把原型做好了.
-
hired ( 程序员拍卖网, 国内已有类似产品: https://hired.com/ )
基于 Rails 构建.
-
dribbble ( 设计师社交平台: https://dribbble.com )
已经是全球设计师社交圈子事实的标准, 基于 Rails 构建.
国内的一些作品:
-
Tower ( 一个项目协作工具: https://tower.im )
完全基于 Rails 构建.
-
36kr ( 创业媒体: http://36kr.com )
基于 Rails 构建.
-
Knewone ( 非常有势头的科技与设计产品社区: https://knewone.com )
完全基于 Rails 构建.
-
100offer ( 另一个程序员拍卖网, 用户体验很出色: http://100offer.com )
完全基于 Rails 构建.
为什么创业公司会优先选择 Rails 作为核心技术栈
作为创业公司的创始人, 你不必:
- 立刻开始做 APP
- 立刻考虑性能瓶颈
- 立刻考虑大量招人
而创业更容易成功的奥妙与核心在于, 以最快的速度打造产品并试水市场
这时, 选择 Rails 往往是最佳的:
-
快速迭代的特性
如果说 Rails 的开发效率在所有框架中排名是第二, 那么我相信没有框架敢轻易说自己是第一.
无论是 Rails 的 15 分钟开发博客系统中提到的脚手架, 还是 CRUD 与 RESTful 整合的天衣无缝, 再加上惯例配置, 能都让 Rails 的开发效率得到极大的提高.
其杀手级特性:
- 惯例配置, 这个特性可以让你的代码写到最少
- 全栈型框架, 包含了 web 最佳实践, 本来各种前端, 后端, 运维一堆人的工作, 现在一个人都可以非常优雅地完成, 例如百度年薪大几十万的前端工程师分享了内部的工作流后, 发现本质上就是 Rails 的布署原理: 大公司前端都在做什么?
- 数据库迁移, 有了它, 快速迭代功能是非常非常简单
- 生态, 类似于 app store, 一个俱复杂的登录注册功能, 在 Rails 中都是 5 行代码的事.
-
快速市场试水与响应能力
Rails 生态的特点就是如何更少更快地写出高可用的代码. 一般来说, 代码越少, 对业务响应能力越强.
simple_formslimscsscoffeescript
类似这样简化业务代码的 gem 非常多, 难怪在前几年, 就有大神呼吁: 超过 3000 行代码的 Rails 就应该拆分了.
除了代码的优化外, 还需要极强的自动化测试才能保证我们能够自由地重构业务, 调整市场方向, 而不致于出现产品 bug 层出不穷的问题.
guardrspecjasminecapybaraselenium-webdriver
这种全自动触发的测试系统在我印象中首创于 Rails, 目前很多框架已经学走了它. 但没关系, Rails 仍然是目前生态最为强大的一个.
如果你将自动测试做好, 快速迭代能力将是十分可怕的.
-
最拥抱 web 最新标准的框架
永远不担心技术栈过时, 这是 Rails 的理想, 也是 web 开发者的最终理想.
Rails 的 RESTful 实现, 是最接近标准的一个. Rails 早在几年就拥抱 coffeescript, 而 Javascript 最新标准 ECMA6 基本与 coffeescript 类似.
Rails 4 开始直接对 mobile 提供支持.
Rails 5 对 API server 提供直接支持.
快速迭代, 市场响应, 以及对于移动互联网的支持, 都是创业公司核心优势. 难怪了很多拥有 Rails 技能的人才一定会选择 Rails 作为公司的核心技术栈, 就是快.
如果你有 Rails 方面的人才, 不选择 Rails 技术栈岂不浪费?
国内的现状与风险提示
国内的 IT 市场往往落后于国际 2 年之久, Rails 方面的人才十分紧缺. 选择 Rails 意味着:
- 招人风险
Rails 招人唯一靠谱的圈子就是 RubyChina, 圈子对于招聘贴有着严格的要求, 如果你想招到优秀的人才, 不仅要有好的待遇与福利, 还需要你的真诚与耐心.
但选择 Rails 的人才会有个极大的优点, 是为了快乐而选择的 Rails, 他们一般也不仅仅只会一种技能, 他们会更积极去学习, 成长与生活.
如果一个高级 Rails 工程师可以顶住两个人的工作量, 你是愿意给两倍工资给他, 还是招两个新手呢?
我会选择前者.
- 性能风险
Rails 会有性能风险, 这是真的, 因为 Rails 与 Ruby 一样, 设计理念是面向程序员的, 而不是机器. 所以它们性能方面都不比其他语言好, 比如 C, C++, Golang, Java.
但从创业公司的经历看, 这个问题现在可以忽略了. 其原因有二:
1) 初期, 用户才是王道, 无关并发性能. 2) 性能往往从 IO 瓶颈开始, 而不是语言性能.
总结
我不算是对各种语言与框架都十分熟悉的人, 但都是有接触的人, 对于 Rails 的优点与缺点, 我私以为是十分的中肯, 我看好 Rails 在创业公司中的应用, 也希望更多的创业公司能够意识到:
选择一个合适的技术栈, 产品将是事半功倍的.
这才是公司除了商业模式外成功的核心秘密.
在 web 界, Rails 是创业公司更优的选择.
还是来咱大 ruby-china 看这篇帖子，舒心，，，这篇文章在 v2ex 上发了，，，好多反对意见，，，，竟然还有人说因为 ruby 效率低不适合创业，，，，太逗了。。。
Rails 的成功案例不太多呀。。。大 Django 成功案例：
- Quora
- Disqus
- Onion
- Hulu
- The Boston Globe
- NYTimes
- Telegraph.co.uk
- Bitbucket
- SourceForge
- edX
其实 Rails 就适合快速 Startup ，创业公司当然喜欢。 就是不好招人，对综合能力和英语要求高。 三年经验的 Rubyist 就可以做 Co-Founder 了，哪个公司敢培养？
#17 楼 @rei 恩。我发现规律了。报业用 django 的特别多。
还有一些 django 写的网站：
- Rdio
- 部分 mozilla.com 页面
- guardian.co.uk
- Mahalo
- Globo.com
- Washington Post
- LA Times
- curse.com
- rasp.yandex.ru
- Pownce(已挂)
来源 http://stackoverflow.com/questions/886221/does-django-scale
码农周边用 rails 的特别多
#15 楼 @est hulu 不是 Rails 成功案例么，怎么叛变啦？http://www.railshosting.org/the-top-10-sites-built-with-ruby-on-rails
For example, RoR was too slow for HULU so they ended up re-coding lots of stuff in C.
補充一個 Why Stripe 選擇使用 Ruby:
http://www.quora.com/Why-did-Stripe-choose-to-use-Ruby-for-its-backend-language
#22 楼 @juanito 但是居然用的是 Sinatra http://www.quora.com/Does-Stripe-use-Rails
#25 楼 @jimrokliu 性能问题不在 ruby 而是在 rails. rails 为了提供最佳实践用了许多 middleware. 不过等增长到需要面对这些性能坑的时候, 多半公司已经成长到相当大的规模了. 这时候无论是迁移到其他更轻的 ruby 框架还是迁移到其他语言, 都已经有能力应付了.
#28 楼 @jimrokliu 16G&i7&SSD MBP 开发慢成狗，说夸张点，启动一次 rails 和我电脑开机时间差不多，性能早晚会上去是多晚？
Ruby 性能没大家说的那么慢，满足绝大多数场景一点问题没有。而性能的问题会随着 Ruby 的不断改进优化而提升上去的，相反 Ruby 社区的那些优点是其他语言永远无法达到的，因为他们没有 Ruby 这种特别的社区文化。
#27 楼 @iBcker #28 楼 @jimrokliu 有过一次迁往 sinatra, 当时 json api 的负载加重, 从 controller 里分离出来. 操作起来要说能轻松迁移确实是不可能做到, 尤其是很多 gem 建立在 rails 的基础之上, 为了这些东西能继续工作写了很多奇奇怪怪的 helper. 有些 gem 干脆就换了. 前后用了大概两周. 其实现在想想当初因为拆分 api 的契机而去把框架换掉也不是很值得, 当时并没遇到性能瓶颈. 测试/文档这部分东西确实很重要, 最早的时候开发为了快轻视了很多这个, 后来发现迭代的时候越来越慢. 现在不敢再这么不管了..
#34 楼 @jimrokliu ruby 的速度可以忍受，但是 rails 的速度无法忍受，启动一个 rails s 得 7、8 秒，部署一次得 1 分钟，对一边刷浏览器一边改程序的来说太虐心了。
我觉得用 ruby mine debug 代码速度太慢了，要等 5 分钟 ，还是 production 模式 真的无法忍受，另外 rails 的性能低是个重要问题，啥时候能解决啊 我觉得开发效率并不一定高，也许我是个新手
#40 楼 @goody9807 试试 development 模式里在需要调试的地方插 byebug 或者 binding.pry. 抛开 IDE 这个东西吧
+----------------------+-------+-------+---------+---------+-----+-------+
| Name | Lines | LOC | Classes | Methods | M/C | LOC/M |
+----------------------+-------+-------+---------+---------+-----+-------+
| Controllers | 7908 | 6380 | 121 | 745 | 6 | 6 |
| Helpers | 1380 | 1199 | 0 | 136 | 0 | 6 |
| Models | 7231 | 5465 | 68 | 567 | 8 | 7 |
| Mailers | 196 | 155 | 5 | 18 | 3 | 6 |
| Javascripts | 5781 | 4491 | 33 | 749 | 22 | 3 |
| Libraries | 1435 | 1117 | 21 | 98 | 4 | 9 |
| Feature specs | 145 | 120 | 0 | 1 | 0 | 118 |
| Model specs | 480 | 390 | 0 | 0 | 0 | 0 |
+----------------------+-------+-------+---------+---------+-----+-------+
| Total | 24556 | 19317 | 248 | 2314 | 9 | 6 |
+----------------------+-------+-------+---------+---------+-----+-------+
Code LOC: 18807 Test LOC: 510 Code to Test Ratio: 1:0.0
包含电商、SNS、API、CMS 四套大模块，也有一些遗留的孤立代码没清理，大概能删掉 2k 左右
