thoughtbot/ruby-science

Ruby on Rails is more than 15 years old and its community has developed a number of principles for building applications that are fast, fun and easy to change: Don't repeat yourself, keep your views dumb, keep your controllers skinny, and keep business logic in your models. These principles carry most applications to their first release or beyond.

However, these principles only get you so far. After a few releases, most applications begin to suffer. Models become fat, classes become few and large, tests become slow and changes become painful. In many applications, there comes a day when the developers realize that there's no going back; the application is a twisted mess and the only way out is a rewrite or a new job.

Fortunately, it doesn't have to be this way. Developers have been using object-oriented programming for several decades and there's a wealth of knowledge out there that still applies to developing applications today. We can use the lessons learned by these developers to write good Rails applications by applying good object-oriented programming.

Ruby Science will outline a process for detecting emerging problems in code and will dive into the solutions, old and new.

Introduction

1. Code Review
2. Smells
3. Resistance
4. Bugs and Churn
5. Tools to Find Smells
6. Navigating
7. Example Application

Code Smells

1. Long Method
2. Large Class
3. Feature Envy
4. Case Statement
5. Shotgun Surgery
6. Divergent Change
7. Long Parameter List
8. Duplicated Code
9. Uncommunicative Name
10. Single Table Inheritance
11. Comments
12. Mixins
13. Callbacks

Solutions

1. Replace Conditional with Polymorphism
2. Replace Conditional with Null Object
3. Extract Method
4. Rename Method
5. Extract Class
6. Extract Value Object
7. Extract Decorator
8. Extract Partial
9. Extract Validator
10. Introduce Explaining Variable
11. Introduce Form Object
12. Introduce Parameter Object
13. Use Class as Factory
14. Move Method
15. Inline Class
16. Inject Dependencies
17. Replace Subclasses with Strategies
18. Replace Mixin with Composition
19. Replace Callback with Method
20. Use Convention Over Configuration

Principles

1. Dry
2. Single Responsibility Principle
3. Tell Don't Ask
4. Law of Demeter
5. Composition Over Inheritance
6. Open Closed Principle
7. Dependency Inversion Principle