该怎么去系统的学ruby on rails

RickyGerry
  • 163

一直它感兴趣,一直被各种问题难倒,想了一下,自己学得太乱,到现在才学了一点点东西。
我想重新开始,来一次系统的洗礼。

回复
阅读 11.3k
2 个回答

好了,有针对性的就你的几个问题简单做一下答复:

资料陈旧的问题

资料陈旧是客观存在的问题,这的确可以理解,不过我要澄清一个误区:学习 Rails 一定要有最新的书籍或资料吗?答案是否定的。

Rails 的发展和版本迭代速度比较快,写书的是很难完全追上它的步伐的。但是无论 Rails 发展的多么快,它的核心框架与基本功能都没有发生太大的变化。《Web 开发敏捷之道》作为 Jolt 获奖书籍是值得一看的,现在市面上最新的中文版本对应的 Rails 版本是……3.2吧,如果我没记错的话。

然而这已经够用了,特别是对于初学者来说,你没有必要一下子掌握所有的细节,如果书中的 API 用法和 Rails 4.1(最新的版本)有出入,直接看一下最新的 API 手册即可。另外还可以参考许多 Rails 社区发表的很多版本更新的文章,比如我曾经在 Rails 4 发布后写的一个:《拥抱 Rails 4 —— 详述 Rails 4 的新变化》。拿着敏捷那本书,对照这些参考资料,你可以掌握 Rails 核心至少八成以上的内容。

另外我不得不说的是,作为一个较为前沿的、小众的社区。Ruby 和 Rails 在书籍的丰富程度上是无法和 Java/C++/C# 之类相比的。书籍不是我们获取 Rails 知识的唯一途径,甚至都不是主要途径。如果你选择 Rails,你必须要融入到整个社区去,很多新鲜的、使用的咨询都是直接来自于社区的所有成员(比如中国的 Ruby/Rails 社区)。等这些东西都汇聚成册出书,你就已经落后了很远了。不过对于初学者来说,落后不要紧,追起来也很快,重要的是基础和全面性的涉猎,这才是本答案的重点——

Rails 是一个框架,而不是一个工具

这意味着什么呢?这意味着,Rails 把几乎所有 Web 开发用得上的、时髦的、前沿的最佳实践都整合在了一起(当然,保持了精简,更多的特性可以用第三方 Gems 来扩充),但是他并不负责告诉你这些最佳实践都是怎么回事?它们在整个 Web 开发里扮演着什么角色?它们的具体用法?

这些东西 Rails 没有直接给你提供答案(这不是它的职责),因此就导致很多初学者一听:十五分钟开发一个博客?!卧槽,这么简单?冲啊……

很遗憾,你错了。抱着这个想法去的,你也许只能学会十五分钟开发一个博客了(这件事对 Rails 来说几乎谈不上技术含量),问题是你不知道这十五分钟里 Rails 都帮你做了哪些事情,所以你始终都觉得在门外徘徊,却无法真正的走进去。

接下来我谈几个重点,前提是你的目标是开发一个 Web 应用,你想学会使用 Rails(系统的学会),那么你需要自行补充下列知识点,最终串联起来形成一个知识体系。到了那时你再用 Rails,才会有登堂入室,融会贯通的感觉。

HTTP

这是所有 Web 开发的前提基础,你不理解 HTTP,你永远无法驾驭 Web 开发,你只能跟着别人(比如 Rails)为你设定好的路数走,而无法随心所欲。但是对于初学者来说,你也没必要追求随心所欲,只要搞清楚最基本的事情就足够了。

我在这里要说一件事,以前我遇到一个女孩子(没有性别歧视),她就是很有想法,很想用 Rails 开发她的创业项目。她遇到了一些细节问题,我帮她作了解答,在过程中我发现她连最基本的 HTTP 请求/响应是什么都不清楚,却一心纠结于设计 RESTful API 和怎么做前端酷炫效果上。我跟她说,慢一点,你花一个月时间(其实用不了那么久)补一下 Web 的基础,然后再搞 Rails,一定会事半功倍,否贼遇到问题你都不知道怎么回事,从哪里下手去解决,你总不能永远都去问别人吧?

她没听,直到今天,她还和一年以前差不多,我看不到她有任何进展。

另外一个女孩子,我带的徒弟,我教了她两个多月(每周大约一天到两天,剩下的时间都是线上辅导),我就是从 HTTP 教起的。两个星期前,她面试 SAP 成功(实习生,还在校念书),面试官给她的评价是:所有面试的实习生里对 HTTP/Web 基本概念掌握的最好的一个,孺子可教。

多的我就不说了,推荐一本书给你:HTTP Developer's Handbook,短小精湛,简洁实用。我花一天就可以读一遍。遗憾的是,这么好的一本书竟然没有中文版!如果你英文吃力,你可以考虑 HTTP 权威指南,但是这本书枯燥乏味,内容很长。对于初学者来说,你需要掌握的东西其实和前者没有区别。

REST

我们都知道 Rails 有一个特点,叫做“约定重于配置”,或者叫“惯例重于配置”。这句话实际是说,对于 Web 开发的一系列通用问题,业界都有一个 Best Practice(最佳实践)。最佳实践未必适合所有的团队和项目,但是对于大多数新团队新项目来说都是值得遵守的。这些通用问题,我们一般可以通过各种配置来定制它们的解决方案,但是 Rails 本着推崇最佳实践的原则,在框架的核心应用了一系列的最佳实践,只要你没有特殊要求,那么你完全不必考虑一大堆复杂的配置问题。

而 REST 就是其中之一,它是 Rails 框架里请求分发与资源管理的核心思想。幸运的是,读完了上面的那本关于 HTTP 的书,你就等于已经掌握了 REST 的基础知识,所以这两件事情原本就是相生相依的。

前端及工作流

Rails 是一个 full-stack(全栈)框架,它对前端也有一整套解决方案,它拥抱最新的技术和实践原则。一般来说 Rails 开发工程师都是(至少半个)全栈工程师,所以你不了解前端是要吃亏的。好多人对于处理数据、业务逻辑、路由等等都不是问题,但却经常陷入前端的坑里半天爬不出来。

对于初学者,你必须掌握基础的 HTML/CSS/Javascript,这个是逃不掉的,否则你就别学 Rails 了。Rails 里有很多基础的机制,其实都是对前端技术的一种 Ruby 实现。比如说 Turbolinks,它的参照物就是 PJax;比如说 Assets Pipeline,它的参照物就是前端的构建工具,例如:GruntGrunt 做的事情更多,还有一部分对应的是 Rake,实际上 Rake 才是对应 Grunt 的,Assets Pipeline 是其中的字集)。

你不必掌握以上工具的细节,但是你最起码应该知道真正的前端开发的完整流程,每一种工具在里面扮演的角色是什么,这样你才能理解为什么会有 TurbolinksAssets Pipeline……等等,遇到问题你才知道需要从何处入手去考虑,去查资料,去解决。

给你一个列表,不要求你学习它们的细节,但是你要知道它们是干什么的,它们解决了什么问题以及工作原理,它们在 Web 开发中的扮演的角色等等。换言之,别人问你这是什么,你应该用一两句话说清楚它们是什么:

  • HTML/Haml/Slim/ERB
  • CSS/Sass/Compass
  • Javascript/Ajax/Coffeescript/Turbolinks
  • JSON/Yaml/XML(这个是通用的,并非只有前端相关)
  • Rake/Grunt/Assets Pipeline

这里面有些是可以和 Rails 不集成在一起实用(比如 Grunt),但是你可以了解一下,因为在 Rails 的世界里,你可以看到它们的身影。有比较,才会有理解。

面向对象设计

归根结底,Rails 是一个基于面向对象的 MVC 框架,所以你得明白什么样的设计是基于面向对象的,MVC 式的分层设计。不过坦白的说,这是一个大坑,初学者很难很快的有所斩获。但是它也很关键,因为它经常回答下列类型的问题:

  • 对于我想要开发的应用/功能,需要多少 models?对应的数据结构应该是什么样的?
  • 对于这些应用/功能需要的行为,应该如何分发在 controllers 里?它们彼此之间如何通讯?如何传递数据?
  • 对于 views 所需要的呈现,我该如何提取/构造/修饰数据或者数据集合?
  • 什么样的情况下可以分拆/组合/……?
  • ……等等等等

一个很现实的问题就是,看教程你会很容易理解为什么会有这些 models/controllers/views/routes 等等,但是轮到你自己解决实际的问题/需求时,你完全不知道该如何下手!这不是 Rails 的问题,而是你不懂用 Rails 来描述你的问题。

所以,看书看教程的时候,你一定不要只是跟着做(第一遍可以无脑跟做),而是要思考,为什么作者要这么设计?用我的思路重新设计一种方案行不行?有没有更好的方案?

每一次你做一个应用的时候,这个应用所有的数据实体应该就如同你的手、脚、眼、口、心一样成为你身体的一部分,它们之间的通讯和数据流转就好像体内的血管一样,看似纷乱,但总是有迹可循,条理分明;而你的大脑控制着一整套神经系统来向各个部件发出指令,就好像路由接收了请求之后做出的分派是一样的。

你能一层层,一点点的把你做的东西讲述清晰吗?如果你可以做到,别说 Rails,世界上任何一个 MVC 框架都不外乎于此。

这个领域的知识不是 Rails 特定的,它也正是你想知道的进阶的部分。

关于 Ruby

学 Rails 要不要先学 Ruby?

  • 如果你在此之前已经有了一门面向对象语言的扎实基础,比如 Python,Javascript,Java 等,那么学习 Rails 不一定要先学 Ruby,而且你肯定也知道该如何去针对性的学习 Ruby。
  • 反之,如果你只有泛泛的学习过任何一门面向对象语言,甚至没有学习过别的语言,你一定需要先学 Ruby,否则 Rails 里一大堆的语法糖/元编程/DSL会把你搞的头晕眼花。

刚接触 Rails 的时候,很多人觉得很神奇,然而“神奇”就等于“未知”,你不能拿着未知的东西来干活,这不是找死么?所以 Ruby 语言的基本功是需要的,你必须能够做到“视神奇如平常”的地步才能毫无滞碍的使用 Rails。对于学习 Ruby,除了镐头书不做其他介绍,进阶的话直接看 Ruby 元编程。

镐头书虽然很厚,但是你要明白至少三分之一都是对标准库 API 的介绍,这部分是可以拿来做参考书的。剩下三分之二,有一小半是 Ruby 语言的整体介绍,而另外一半才是语言的细节。因此你真正需要精读的部分也就三分之一多一点。我刚开始的时候每天坐地铁的时候读几页,前后也就一个来月精读了一遍。

镐头书有中文版,虽然版本低不过无妨,基本的东西没怎么变。看完中文版的,然后找一本新的英文版,新书里所有版本变化的地方都有明确标示,你可以对照着看一下这些点,升级工作就 OK 了。

另外,学习 Ruby 和 学习 Rails 实际上可以同步进行,不会耽误多少时间的。

时间?

我觉得一个智商正常,有一定自律性,有一定文化基础的人,学习我上面提到的东西(除了 OO 设计这个大坑)按每天 4 小时计算,半年下来应该小有成效了,也就是共计 720 小时。

什么,你说慢?拜托~720 小时打下一个可以成长为全栈开发工程师的基础,这已经是火速了好吗?人啊,要有远见!

其他

还有一些东西没说,比如测试,比如部署,比如命令行等等,这些都是 Rails 开发中的日常任务,没什么好说的。只要你用 Rails 你就不可能学不会。

结语

Rails 是简单,十五分钟开发博客什么的那都是 2006 年的往事了,到了今天它的开发效率更是令人发指。但是综上所述你应该明白,Rails 高效的背后是框架帮助你封装和隐藏了一系列前沿的工具、技术、最佳实践。你不用从头开始重复去实现它们(所以你获得了高效率)并不代表你不需要知道它们(你得了解高效率背后的技术细节)。否则的话你永远只能重复别人十五分钟做出来的东西,轮到你自己的时候给你再多的十五分钟,你不会的还是不会。

资源

补充点资源。学习 Rails 最好的视频教程在:Code School

不要怕花钱,一个月 25 美金,折合人民币才 160 块不到,你知道这一个月你能学到多少东西吗?上去看看吧!(我不是打广告,我和 CS 没有任何关系,纯推荐)


哎!我这啰嗦的毛病始终改不了,原打算几个点随便说几句,一不留神又长篇了……题主啊,以后不要问这么宽泛的问题了我求你,否则我这样的强迫症患者会吃不消的。

我建议你,参照我的答案,以及别人的建议,自己给自己画一副路线图。给自己一个时限(比如半年,每天4小时之类的),然后根据路线图制定一个学习计划。如果你心里没谱,你可以把路线图发给大家帮你参详参详。我当初就这么做了,我做了好大一个 Mindmap 呢,也获得了好多热心人给我发来的指导意见,受益匪浅。

之后你每走一步,碰到的具体问题先学会自己分析,然后上网搜索答案,实在找不到答案了,再发到 SF 这样的社区来求助。这样才能做到具体问题具体分析,而不是像我这样啰哩啰嗦一大堆实际上没啥干货,也只有这样你才能真正的把本事学到手,而不是茫然若失被别人牵着鼻子走。

另外,刚入社会碰碰壁也是很正常的。别灰心,把经历变成经验,最重要的是保持一个稳定的心态。祝你好运!

资料:

Rails 还是学习最新版比较好。中文的好教程不多,ruby china的guides算一个,不过那是文档型的,容易感觉枯燥.

英文的我推荐两个:

  1. Agile Web Development with Rails 4: 特点是,第一部分给了一个项目,边做边学各种Rails功能,并且有测试。第二部分讲专题。DHH作品。很适合入门。
  2. The Rasil 4 Way: 第一本读完后,看这本。讲解更深入一些。

资料不在于多,而在于看进去,看透彻

就这两本足够入门了。

有些比较好的专题书:

  1. The Rails View: 如何写出优美的view template。
  2. Deploying Rails: 部署和服务器监控专题

还有很多,不一一列举了。pragprog.com去找吧。有关于测试的专题

这个阶段过去,可以补一补Ruby了。尤其是这本Metaprogramming Ruby。如果觉得这个比较长,那么广告时间,这个是我的博客,关于这本书的笔记

方法很重要

我自己的学习方式是,我当初想做一个项目,或者我想用某个成熟的点子来练手(比如自己做个微博或者论坛)。我一边看书,一边把学到东西用到自己的项目中。这个好处是,避免了单纯重新抄书上的例子,学习效率高

你知道吗?

宣传栏