28
SO YOU WANT TO START REFACTORING? JILLIAN FOLEY • RAILSCONF 2015

So You Want to Start Refactoring?

Embed Size (px)

Citation preview

S O Y O U W A 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

A B O U T M E

•Software engineer at Contactually

•Learned coding on-the-job

•Pretty much only worked in legacy code

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

– 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."

T H E I D E A I S

• No change to your users

• Improvement for developers

B U T … W H Y ?

– Y O U R M A N A G E R

“Refactoring? No way. We need new features!”

• Maintainability

• Scalability

• Flexibility

• Spring cleaning

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 ?

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 KWINTER IS COMING

TESTS ARE HARD TO WRITE

BLOCKING NEW PROGRESS

PRODUCTION CRASHES

D O I T Y E S T E R D AY !

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

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

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

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

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

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

!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 != "[email protected]" 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

# 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 != "[email protected]" 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

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 == '[email protected]' 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

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 . . .

OMG I WANT ALL THE CHANGES!!!11

“BIG BANG”

SLOW AND STEADY WINS THE RACE?

“INCREMENTAL”

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

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

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

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