Book Image

Polished Ruby Programming

By : Jeremy Evans
5 (1)
Book Image

Polished Ruby Programming

5 (1)
By: Jeremy Evans

Overview of this book

Anyone striving to become an expert Ruby programmer needs to be able to write maintainable applications. Polished Ruby Programming will help you get better at designing scalable and robust Ruby programs, so that no matter how big the codebase grows, maintaining it will be a breeze. This book takes you on a journey through implementation approaches for many common programming situations, the trade-offs inherent in each approach, and why you may choose to use different approaches in different situations. You'll start by refreshing Ruby fundamentals, such as correctly using core classes, class and method design, variable usage, error handling, and code formatting. Then you'll move on to higher-level programming principles, such as library design, use of metaprogramming and domain-specific languages, and refactoring. Finally, you'll learn principles specific to web application development, such as how to choose a database and web framework, and how to use advanced security features. By the end of this Ruby programming book, you’ll be a well rounded web developer with a deep understanding of Ruby. While most code examples and principles discussed in the book apply to all Ruby versions, some examples and principles are specific to Ruby 3.0, the latest release at the time of publication.
Table of Contents (23 chapters)
1
Section 1: Fundamental Ruby Programming Principles
8
Section 2: Ruby Library Programming Principles
17
Section 3: Ruby Web Programming Principles

Learning about the refactoring process

In general, the process of refactoring existing code is similar to writing code in the first place. In many cases, it's even easier. Assuming you've followed the advice in Chapter 11, Testing to Ensure Your Code Works, you already have a good set of tests for the behavior you are refactoring. If you've inherited code without tests or with tests that don't give you good confidence that they will catch bugs that can be introduced during refactoring, before you start refactoring, the goal should be to get the tests in a good enough shape that you are comfortable that they will catch you if you fall. If you are in a position where you refactor some code and run the tests and everything passes, and your first thought is, "Maybe I am missing a case where this fails," then you probably don't have enough tests. You can add tests at that point, but that's not the best time. What if you add the tests after refactoring...