Effective Ruby LiveLessons——Sam Phippen 访谈

由 Sam Phippen 制作的 Effective Ruby LiveLessons ，是一系列讲解了专业的 Rubyists 的最佳实践的视频教程，它针对各个阶层的 Ruby 程序员。这个系列的视频基于 _Effective Ruby__，_Peter Jones 所著的有效的软件开发系列丛书之一。

视频教程包含了亲自示范，来帮助观看者理解每个项目是如何实行的。InfoQ 和制作者谈了一些有关视频中可以学到的课程，以及 Ruby on Rails 的最佳实践。

InfoQ: Nil被许多的Ruby程序员用于检查方法的返回值。你认为在检查方法的返回值时，是抛出异常好还是使用nil**** 好？

我之前确实有谈过这个主题；可以点击这里查看幻灯片。在这里使用 nil 的核心问题是 nil 没有一些其他对象含有的操作。这导致了从一个方法返回它的时候是有问题的。这样做强迫了调用方注意到你的方法调回对象没有按照相同的接口。这是非常有问题的。

说到抛出异常，我也并不非常确定这是一个好的解决方法。这完全取决于上下文。对我来说，这个问题提出的两个分支并不是很准确。当你在面对执行一个不可靠的方法时，我认为会有其他更好的选择。我会寻找一些明显意味着“空容器”或“默认值”的这类型的方法。如果不可能的话那我会看一些类似于选项类型实现的方法作为替代。

InfoQ: 你对于方法链以及遵从得墨忒耳定律的建议是什么？

得墨忒耳定律，是一项定律。但是，要注意：得墨忒耳定律经常被人误解。在我的 LiveLessons 上，我特别指出的是，这个定义让你在同一类型中点链。当我对得墨忒耳渐渐有更多了解时，对我而言它真正的意义在于：不要跨越体系结构的边界传递信息。这是比“不要点链”更难以表达解释的概念的一种方式。举例来说，我完全可以接受用方法链来建立活动记录范围。在那种情况下，你不仅不能跨越体系结构的边界，你事实上还只是在一个单独对象上修改状态。

所以我猜想，对，遵循得墨忒耳定律，但在你对它过于虔诚之前先了解它意味着什么。

InfoQ: RoR运用于网络空间的很大一部分。你认为它已经影响了多少在Ruby**** 和其他更严格类型化的语言中的异常相关最佳实践？

Ruby on Rails 使用各式各样的技术来处理异常情况。我不确定我是否赞同 Ruby 使用异常作为最佳实践。我会说，类型系统给了我们提前于运行时间的大量安全性，这是 Ruby 所不能提供给我们的，并且在那些地方，异常可以变得相当方便。

InfoQ:一个Ruby**** 开发者在测试他们的代码时应该更多依靠部件或行为测试吗？

当谈到写测试的时候，专注于建立一个为你和你的团队工作的测试结构是很重要的。确实，现代测试练习就是敏捷的一个方面。敏捷可以带给我们的最好的东西就是一套用来修改随着时间推移修改我们团队工作方式的工具。这就意味着我们的测试练习也应该随着时间不断变化。换句话来说，我认为各个应用程序和团队会影响是什么做出了最好的测试，而不是一些社区指令。

InfoQ:你可以给Ruby on Rails apps**** 中的数据资源使用监控提些建议吗？

使用 New Relic。New Relic 是让我成为一个好的顾问的秘诀所在。能够弹出那些图表以及获得大量的洞悉力是十分有帮助的。

InfoQ:你是如何看待在Ruby和Rails中测试的？有抱负的程序员应该坚持使用Ruby和Rails**** 提供的默认测试工具或者接触其他测试框架？

我在 RSpec 的核心团队中，所以很显然我这里的答案是很有偏倚的。我对“我应该使用哪一种测试框架？”的典型反应是：“这是视情况而定的。” Minitest 有一套非常集中和限制的功能，但是这对你没有关于 RSpec 的应用程序有一定的限制。也许你会发现那些限制有用，并且其本身应该使用 minitest。RSpec 是测试框架的一个强有力的庞然大物。我喜欢说，如果你能想象一个测试，你就可以在 RSpec 上写出来。为此目的，RSpec 让你编写和测试你想要的任何代码。这里可能会有的问题就是，你的设计是弱于它的。RSpec 也擅长于测试遗留代码，所以如果你有一个遗留的应用程序，这可能是好事。再次地，警告和取舍。选择一个适合自己的。

InfoQ: 你可不可以提供更多关于Ruby中的 ****lambda 和 proc**** 的信息以及为什么两者只能择其一呢？

如果我必须要自己实际建立一个，我会一直使用 lambda。这就是去处理 lambda 如何得到堆栈帧相对于 proc。当你在 ruby 中创建一个块时，你总是要去分配一个 proc，所以那就是你要日复一日要去使用它们的地方。

InfoQ: 在编程中处理日期是在每种语言中最困难的问题之一。你对于日期时间库以及最佳实践给有抱负的 Ruby 程序员的建议是什么？

在我的 LiveLessons 上我给出了一个建议，但真实的答案会稍微复杂一点。这取决于你的应用程序、数据库以及一堆其他因素。更重要的是，最佳实践会随着时间不断变化。因此，我会建议查找目前的最佳实践并且实施它。

InfoQ:记忆—在Ruby中，这和其他设计模式对有抱负的程序员都非常感兴趣。你会给想提高自己的编程技能的新手到中级Ruby开发者除了LiveLessons**** 系列以外推荐什么呢？

看 Sandi Metz 的 Practical Object-Oriented Design in Ruby: An Agile Primer 。然后，再看一遍。当谈到处理对象时，Sandi 毫无疑问地搞定了。这本书将改变你如何永久编写 Ruby 并且向好的方向发展。

InfoQ:你看有哪些其他语言的坏习惯在大部分时间折磨着RoR**** 程序员呢？

过于势在必行。我认为这导致人们会认为他们不能提取对象并且导致系统设计不佳。每当我与初学者 / 刚进入 Ruby 的人工作时，我让他们比在其他方面我会做到的更经常地提取对象。这只是为了确保他们知道这样做是可以的并且它将铸成一个更好的系统。

InfoQ:你可以讨论一下在Ruby中隐藏继承层次如何运作以及如何与其他语言比如Java，在继承上进行比较？

简单地说，每一个对象都会得到一个单例类，这个单例类在继承链中是看不见和直接的。他可以被用来在不修改该类型的所有其他对象的前提下，在单独对象中添加方法。Java 没有这个，我猜测，因为你通常不会在 Java 中动态修改类？一个更完整的解释大概需要一千个单词，并且会覆盖 Ruby 中的大部分元编程架构。在未来，我可能会有一本书来把这个解释包含在内。

InfoQ:你能谈一谈Ruby**** 中的分代垃圾收集器以及在配置它时，开发者需要考虑的任何因素吗？

我真的从来没有配置过垃圾收集器。说实话，从我看到的来说，Ruby 核心团队一直在持续不断的工作，为了常见的（阅读 Rails）工作量来优化它。因此，对于内部构件我不知道太多。但是，这是关于 Ruby 的一件很好的事情。为了能够编写语言，我不需要去知道 GC 的内部构件。

关于作者

Sam Phippen是来自英国伦敦的一名传奇的电脑黑客。他在 Fun and Plausible Solutions 有限公司修正了各种大小的数据问题。他作为 RSpec 核心团队的成员，帮助争取正义的力量。他很难过，他不能拥抱每一只猫。

查看英文原文： Effective Ruby LiveLessons - An Interview with Sam Phippen

感谢张龙对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们，并与我们的编辑和其他读者朋友交流（欢迎加入 InfoQ 读者交流群（已满），InfoQ 读者交流群（#2））。