Refactoring Your Rails Application
Location: Portland Ballroom 253 Audience level: Intermediate
Paper: Refactoring Your Rails Application Paper [PDF]
Refactoring is an essential part of a developer’s life. It can be difficult to know when or what to refactor in a Rails application. Some common and more noticeable signs that you need to refactor are:
- controllers becomes bloated
- models become bloated
- the view ends up embedding logic within its template
- view helpers become large and complex, both in size and in number of methods
- view partials rely on instance variables and constants rather then local variables
- models start doing work for the view
- tests become large, complex and painful to maintain
Refactoring should be a continual process throughout the life of an application. In order to refactor well it requires the developer to have proper techniques, tools and discipline. For example:
- applying the single responsibility principle
- extracting objects from bloated methods
- splitting objects into two
- identifying what goes in a model and what doesn’t
- identifying what goes in a controller and what doesn’t
- extracting presenters
- when to use classes and when to use modules
- using integration tests to help you refactor
- writing better tests
- writing clear and meaningful code
In this talk we will show the audience how to use the above refactoring techniques and tools to keep their Rails project humming along through development. Not only will they be able to apply these techniques to existing code, but they will be able to use these techniques to write better code from this point forward.
People planning to attend this session also want to see:
Before joining Atomic Object Zach spent the previous six years developing software including a visual sales tool and web-based project management system for one of the nation’s largest companies.
Zach is passionate about solving problems and believes in ongoing improvement to the methods and practices used in solving those problems. He agrees that people matter most and is very interested in improving the communication between technical developers and non-technical business people.
His passion about software development led him to learning Ruby in late 2002. In 2005 Zach started developing with Rails and by 2006 he was developing with Ruby and Rails full time. In February 2005 Zach started the Michigan Ruby Users Group. In late summer of 2006 he helped organize and spoke at the first annual RubyConf*MI. He has contributed to Ruby’s standard library documentation and to Rails as well as authoring and maintaining plugins like ActiveRecord::Extensions, form_test_helper, view_tests and test_unit_story_runner. He is an active member of the Ruby, Rails and RSpec communities.
In his spare time Zach runs Continuous Thinking, http://www.continuousthinking.com .
Drew Colthorp is a software developer at Atomic Object, a consulting company based out of Grand Rapids, Michigan. He has been working with ruby since 2004 and Rails since 2005.