精通Ruby编程实践

需积分: 9 163 浏览量更新于2024-07-26 收藏 2MB PDF 举报

"Ruby实践-Ruby.Best.Practices" 是一本由Gregory T Brown编写的书籍，中文名为《Ruby最佳实践》，旨在帮助程序员提升在Ruby编程语言中的专业技能，实现编写更加优雅、高效的代码。该书是英文版，由O'Reilly出版社出版，书号为978-0596523008，于2009年6月发行。书中涵盖了多种主题，包括测试驱动开发、API设计、动态工具的掌握、文本处理和文件管理、函数式编程技术、错误处理、降低文化障碍、项目维护以及编写兼容性代码和利用Ruby标准库的策略。书中的内容深入浅出，不仅讲解了如何利用Ruby的代码块功能，还探讨了如何在不破坏现有代码结构的情况下进行扩展，如运行时在模块内的融合。测试与调试章节介绍了如何从可测试性角度进行设计，以编写更简洁的代码。此外，书中还提到了针对文本处理和文件管理的开发方法，如使用正则表达式。在函数式编程技术方面，作者阐述了如何运用这些思想和技术，使代码更加简洁，提高编程效率。当程序出现问题时，如何正确处理错误也是本书的重要部分，它指导读者如何在遇到问题时进行有效的调试和修复。除此之外，书中还讨论了如何跨越不同的编程文化，以促进团队间的合作，并给出了维护项目的一些建议。附录部分包含了编写向后兼容代码的指南，充分利用Ruby标准库的方法，以及避免的Ruby编程反模式，这些都对提高代码质量有着显著的帮助。《Ruby最佳实践》是一本全面而深入的Ruby编程指南，对于希望提升Ruby编程水平，写出更具表现力和可维护性的代码的开发者来说，是一份宝贵的参考资料。

permission. Selling or distributing a CD-ROM of examples from O’Reilly books does

require permission. Answering a question by citing this book and quoting example

code does not require permission. Incorporating a significant amount of example code

from this book into your product’s documentation does require permission.

We appreciate, but do not require, attribution. An attribution usually includes the title,

author, publisher, and ISBN. For example: “Ruby Best Practices by Gregory Brown.

If you feel your use of code examples falls outside fair use or the permission given here,

feel free to contact us at permissions@oreilly.com.

Safari® Books Online

When you see a Safari® Books Online icon on the cover of your favorite

technology book, that means the book is available online through the

O’Reilly Network Safari Bookshelf.

Safari offers a solution that’s better than e-books. It’s a virtual library that lets you easily

search thousands of top tech books, cut and paste code samples, download chapters,

and find quick answers when you need the most accurate, current information. Try it

for free at http://my.safaribooksonline.com.

How to Contact Us

Please address comments and questions concerning this book to the publisher:

O’Reilly Media, Inc.

1005 Gravenstein Highway North

Sebastopol, CA 95472

800-998-9938 (in the United States or Canada)

707-829-0515 (international or local)

707-829-0104 (fax)

O’Reilly has a web page for this book, where we list errata, examples, and any additional

information. You can access this page at:

http://oreilly.com/catalog/9780596523008/

Gregory maintains a community-based page for this book at:

http://rubybestpractices.com

To comment or ask technical questions about this book, send email to:

bookquestions@oreilly.com

For more information about our books, conferences, Resource Centers, and the

O’Reilly Network, see our website at:

xiv | Preface

http://www.oreilly.com

Acknowledgments

Over the course of writing Ruby Best Practices, I was thoroughly supported by my

friends, family, and fellow hackers. I want to thank each and every one of the folks

who’ve helped out with this book, because it would not exist without them.

This book did not have a typical technical review process, but instead was supported

by an excellent advisory board whose members participated in group discussion and

the occasional review as each chapter was released. These folks not only helped catch

technical errors, but helped me sketch out the overall vision for how the book should

come together as well. Participants included James Britt, Francis Hwang, Hart Larew,

Chris Lee, Jeremy McAnally, and Aaron Patterson.

Rounding out the group was the best pair of guiding mentors I could hope for, Brad

Ediger and James Edward Gray II. Both have published Ruby books, and have worked

with me extensively on a number of Ruby projects. James and Brad were both instru-

mental in producing this book, and to my career as a software developer in general. I

have learned a ton from each of them, and thanks to their help with RBP, I can now

pass their knowledge on to you.

Much of the source code in this book comes from the open source Ruby community.

Although I talk about my own projects (Prawn and Ruport) a lot, most of the code I

show is actually from other contributors or at least originated from good ideas that

came up in mailing list discussions, feature requests, and so on. In addition to these

two projects, I also have benefited from studying a whole slew of other gems, including

but not limited to: activesupport, builder, camping, faker, flexmock, gibberish, haml,

highline, lazy, nokogiri, pdf-writer, and rspec. Great thanks go out to all of the devel-

opers of these projects, whom I’ve tried to acknowledge directly wherever I can

throughout the text.

Of course, without Yukihiro Matsumoto (Matz), we wouldn’t have Ruby in the first

place. After writing this book, I am more impressed than ever by the language he has

designed. If I’m lucky, this book will help show people just how beautiful Ruby can be.

Producing the technical content for this work was daunting, but only part of the overall

picture. My editor, Mike Loukides, and the entire O’Reilly production team have made

publishing this book a very comfortable experience. After overcoming major fears

about the hurdles of working with a mainstream publisher, I’ve found the folks at

O’Reilly to be helpful, accommodating, and supportive. It is especially nice that this

book will become an open community resource less than a year after it prints. This

measure is one I hope to see other technical book publishers adopt, and one I’m very

thankful that O’Reilly was open to.

Preface | xv

CHAPTER 1

Driving Code Through Tests

If you’ve done some Ruby—even a little bit—you have probably heard of test-driven

development

(TDD). Many advocates present this software practice as the “secret key”

to programming success. However, it’s still a lot of work to convince people that writing

tests that are often longer than their implementation code can actually lower the total

time spent on a project and increase overall efficiency.

In my work, I’ve found most of the claims about the benefits of TDD to be true. My

code is better because I write tests that document the expected behaviors of my software

while verifying that my code is meeting its requirements. By writing automated tests, I

can be sure that once I narrow down the source of a bug and fix it, it’ll never resurface

without me knowing right away. Because my tests are automated, I can hand my code

off to others and mechanically assert my expectations, which does more for me than a

handwritten specification ever could do.

However, the important thing to take home from this is that automated testing is really

no different than what we did before we discovered it. If you’ve ever tried to narrow

down a bug with a print statement based on a conditional, you’ve already written a

primitive form of automated testing:

if foo != "blah"

puts "I expected 'blah' but foo contains #{foo}"

end

If you’ve ever written an example to verify that a bug exists in an earlier version of code,

but not in a later one, you’ve written something not at all far from the sorts of things

you’ll write through TDD. The only difference is that one-off examples do not ade-

quately account for the problems that can arise during integration with other modules.

This problem can become huge, and is one that unit testing frameworks handle quite

well.

Even if you already know a bit about testing and have been using it in your work, you

might still feel like it doesn’t come naturally. You write tests because you see the long-

term benefits, but you usually write your code first. It takes you a while to write your

tests, because it seems like the code you wrote is difficult to pin down behavior-wise.

In the end, testing becomes a necessary evil. You appreciate the safety net, but except

for when you fall, you’d rather just focus on keeping your balance and moving forward.

Masterful Rubyists will tell you otherwise, and for good reason. Testing may be hard,

but it truly does make your job of writing software easier. This chapter will show you

how to integrate automated testing into your workflow, without forcing you to relearn

the troubleshooting skills you’ve already acquired. By making use of the best practices

discussed here, you’ll be able to more easily see the merits of TDD in your own work.

A Quick Note on Testing Frameworks

Ruby provides a unit testing framework in its standard library called minitest/unit. This

library provides a user-level compatibility layer with the popular test/unit library, which

has been fairly standard in the Ruby community for some time now. There are signif-

icant differences between the minitest/unit and test/unit implementations, but as we

won’t be building low-level extensions in this chapter, you can assume that the code

here will work in both minitest/unit and test/unit without modification.

For what it’s worth, I don’t have a very strong preference when it comes to testing

frameworks. I am using the Test::Unit API here because it is part of standard Ruby,

and because it is fundamentally easy to hack on and extend. Many of the existing

alternative testing frameworks are built on top of Test::Unit, and you will almost cer-

tainly need to have a working knowledge of it as a Ruby developer. However, if you’ve

been working with a noncompatible framework such as RSpec, there’s nothing wrong

with that. The ideas here should be mostly portable to your framework of choice.

And now we can move on. Before digging into the nuts and bolts of writing tests, we’ll

examine what it means for code to be easily testable, by looking at some real examples.

Designing for Testability

Describing testing with the phrase “Red, Green, Refactor” makes it seem fairly straight-

forward. Most people interpret this as the process of writing some failing tests, getting

those tests to pass, and then cleaning up the code without causing the tests to fail again.

This general assumption is exactly correct, but a common misconception is how much

work needs to be done between each phase of this cycle.

For example, if we try to solve our whole problem all in one big chunk, add tests to

verify that it works, then clean up our code, we end up with implementations that are

very difficult to test, and even more challenging to refactor. The following example

illustrates just how bad this problem can get if you’re not careful. It’s from some payroll

management code I wrote in a hurry a couple of years ago:

2 | Chapter 1: Driving Code Through Tests

剩余329页未读，继续阅读

huzhouhzy

粉丝: 83
资源: 1657

精通Ruby编程实践

rubygems

Ruby最佳实践Ruby Best Practices

Ruby Best Practices

tdd-best-practices

best-practices-checklist:很棒的惯用代码资源列表。 Rust，Go，Ruby，Pony，Ocaml，Erlang等

Ruby-Ruby技巧惯用Ruby重构和最佳实践

rspec-best-practices：RSpec代码示例

matlab代码安全-awesome-best-practices:精选的很棒的最佳做法清单

awesome-ruby-cli-apps:Ruby中很棒的命令行应用程序的精选列表

awesome-ruby-security：很棒的Ruby安全资源

最新资源