The document discusses refactoring code to improve its structure and design without changing its external behavior. It defines refactoring, explains why it is important for maintainability and flexibility, and provides tips on how to refactor code through preparation, annotation, investigation, and cleanup. An example of refactoring a signup controller is used to illustrate how to simplify conditionals, use more descriptive names, and consolidate duplicate logic. The key lessons are that refactoring improves code quality over time, is best done incrementally with testing, and is an important skill for all developers to learn.

1. S O Y O U WA N T T O
S TA R T R E FA C T O R I N G ?
J I L L I A N F O L E Y • R A I L S C O N F 2 0 1 5

2. A B O U T M E
•Software engineer at
Contactually
•Learned coding on-the-job
•Pretty much only worked in
legacy code

4. S O W H AT I S R E FA C T O R I N G ?

5. – M A R T I N F O W L E R
“Refactoring is a disciplined technique for
restructuring an existing body of code, altering its
internal structure without changing its external
behavior."

6. T H E I D E A I S
• No change to your users
• Improvement for
developers

8. B U T … W H Y ?

9. – Y O U R M A N A G E R
“Refactoring? No way. We need new features!”

10. • Maintainability
• Scalability
• Flexibility
• Spring cleaning

11. H O W W I L L I K N O W W H E N I T ’ S T I M E
T O R E FA C T O R ?

12. O V E R W H E L M E D B Y
B U G S
D E C R E A S E D
P E R F O R M A N C E
N 0 0 B S AY S W T F
TA K E A L O O K
WINTER IS COMING

13. TESTS ARE HARD TO
WRITE
BLOCKING NEW
PROGRESS
PRODUCTION CRASHES
D O I T Y E S T E R D AY !

14. S O H O W D O Y O U D O I T ?

15. P R E PA R E
• Beef up your test
coverage
• Review functionality x 100
• Brush up on code style
guides and preferences
M I S E E N P L A C E , F O R C O D E

16. A N N O TAT E
• Read through and comment
anything that looks weird,
bad, wrong, or confusing
• Consider copying
dependencies temporarily
• Rename variables and
methods
M A R K U P S M E L LY C O D E

17. I N V E S T I G AT E
•What looks redundant?
•What looks too complex?
•What parts of the code took more
than 1-2 reads to understand?
•Do you see any methods that
look bloated?
•Does any of it violate code style
standards?
L O O K F O R C O D E M E S S E S

18. C L E A N U P
• Focus on one method at a time
• DRY it up
• Pick better names
• Fix style issues
• Simplify conditionals
• Break down complex methods
• Move code where it truly belongs
G I V E Y O U R C O D E A M A K E O V E R

19. A V E RY B R I E F C A S E S T U D Y

20. !
email = params[:signup].delete(:email).to_s.gsub(/s/, '').downcase[0..100]
!
!
unless u = User.find_by_email(email)
if a = Account.email.find_by_username(email)
!
u = a
end
end
!
!
if u
if email != "demo@contactually.com"
flash[:notice] = "Looks like you already have an account."
redirect_to new_user_session_path(:exists => true)
return true
!
else
sign_in(u)
redirect_to signup_accounts_path
return true
end
end

21. # Does this assignment need to be so long? Why is the param key :signup ?
email = params[:signup].delete(:email).to_s.gsub(/s/, '').downcase[0..100]
!
# This nested unless/if makes my brain hurt.
unless u = User.find_by_email(email)
if a = Account.email.find_by_username(email)
# Is there some way to consolidate these two u assignments?
u = a # wtf are these single-letter variables
end
end
!
# Ew another nested if
if u
if email != "demo@contactually.com"
flash[:notice] = "Looks like you already have an account."
redirect_to new_user_session_path(:exists => true)
return true
# Using the negative in the first if makes this 'else' confusing
else
sign_in(u)
redirect_to signup_accounts_path
return true
end
end

22. email = params[:user][:email]
!
# Try to find an existing user by email or account
existing_user = User.find_by_email(email) ||
Account.email.find_by_username(email).try(&:user)
!
# Push demo user through to demo signup
if existing_user && email == 'demo@contactually.com'
sign_in(existing_user)
redirect_to signup_accounts_path
return true
end
!
if existing_user
flash[:notice] = "Looks like you already have an account with
Contactually."
redirect_to new_user_session_path(:exists => true)
return true
end

23. O T H E R T I P S
• Test frequently, both manually and automated.
• Don’t change tests while refactoring!
• Commit frequently.
• Use tools like Rubocop or Reek for help when you’re
overwhelmed or stuck
• Consider pausing after a logical group of changes to
do more testing, code review, and deploy . . .

24. OMG I WANT
ALL THE
CHANGES!!!11
“BIG BANG”
SLOW AND
STEADY WINS
THE RACE?
“INCREMENTAL”

25. T H I N G S T O R E M E M B E R
• Refactoring isn’t scary
• It’s a good way to learn new design patterns
• It’s a good way to learn your codebase
• Tests can be refactored too!
• Go back and refactor old projects for practice

26. G O F O R T H A N D R E FA C T O R !

27. Q U E S T I O N S ?
J I L L I A N @ C O N TA C T U A L LY. C O M
@ J 3 F O L E Y

28. A P P E N D I X : F U R T H E R R E A D I N G
!
• Martin Fowler's site to accompany his Refactoring book
• The Ruby version of above Refactoring book, by Jay
Fields, Shane Harvie, and Martin Fowler
• Ginny Hendry's notes from the Ruby version of the
Refactoring book
• Codecademy Ruby refactoring exercise