4 Simple Rules to Refactoring

4 SIMPLE RULES TO REFACTORING
STEVEN YAP, FUTUREWORKZ

StevenYap
stevenyap@futureworkz.com
https://github.com/stevenyap

COUNTRY = SINGAPORE
STATE = SINGAPORE
CITY = SINGAPORE
CAPITAL = SINGAPORE

• Host Saigon.rb Ruby Meetup
• Co-Founder of Futureworkz
• Ruby on Rails coder
• Agile startup consultant

Awesome Ruby on Rails Development
http://www.futureworkz.com
http://playbook.futureworkz.com/

4 SIMPLE RULES TO REFACTORING BY STEVEN YAP
I HATE REFACTORING BECAUSE...
▸ extra work to do
▸ what if i break something else?
▸ waste of time
▸ takes up too much time
▸ no time
▸ don't know what to refactor
▸ how to refactor?
▸ i can't see the code smell
▸ makes me feel stupid
▸ any other reasons?

HATE REFACTORING
😡😡😡😡

4 SIMPLE RULES TO REFACTORING
HTTP://PLAYBOOK.FUTUREWORKZ.COM/PROTOCOLS/CODE-REVIEW/INDEX.HTML

LOVE REFACTORING
😍😍😍😍

THE FOUR RULES
▸ Write Test Cases
▸ Don't Repeat Yourself (DRY)
▸ Naming Reveals Intention
▸ Single Responsibility Principle (SRP)

RULE #1: WRITE TEST CASES
▸ No test cases = no refactoring
▸ Never try to refactor without a test case to cover you
▸ Other coders' test cases protect you too
▸ Stress-free in coding = more happiness
▸ Easy way to write test cases (self-promotion): 
http://blog.futureworkz.com/ruby-on-rails/easy-way-write-test-case/
▸ The more test cases you write, the faster you write the test cases

require 'rails_helper'
describe Program do
context 'validations' do
it { is_expected.to validate_presence_of :name }
it { is_expected.to validate_presence_of :category_id }
it { is_expected.to validate_presence_of :team_id }
it { is_expected.to validate_presence_of :estimated_start_date }
it { is_expected.to enumerize(:status).in(:wip, :unsuccessful, :pending_approval, :approved, :rejected, :completed) }
end
context 'associations' do
it { is_expected.to have_one :job }
it { is_expected.to have_many :quotations }
it { is_expected.to have_many :pos_to_suppliers }
it { is_expected.to have_many :pos_to_suppliers_in_group }
it { is_expected.to have_many :approved_quotations }
it { is_expected.to have_many :cost_items }
end
describe '.started' do
let!(:pending_program) { create(:pending_program) }
let!(:started_program) { create(:approved_program) }
it 'returns an array of started program' do
expect(Program.started).to include started_program
expect(Program.started).to_not include pending_program
end
end
end

HATE REFACTORING
😍😡😡😡

RULE #2:
DON'T REPEAT YOURSELF

class ShoppingCart
has_many :products
def final_price
products.map(&:price).inject(&:+) + country_tax
end
def country_tax
products.map(&:price).inject(&:+) * 0.1
end
end

class ShoppingCart
has_many :products
def final_price
total_price + country_tax
end
def country_tax
total_price * 0.1
end
def total_price
products.map(&:price).inject(&:+)
end
end
class ShoppingCart
has_many :products
def final_price
products.map(&:price).inject(&:+) + country_tax
end
def country_tax
products.map(&:price).inject(&:+) * 0.1
end
end

class Order < ActiveRecord::Base
def pending?
status == :pending
end
def paid?
status == :paid
end
def delivered?
status == :delivered
end
def cancelled?
status == :cancelled
end
def refunded?
status == :refunded
end
end

STATUSES = [:pending, :paid, :delivered, :cancelled, :refunded]
STATUSES.each do |status_name|
define_method "#{status}?" do
status == status_name
end
end
end
def pending?
status == :pending
end
def paid?
status == :paid
end
def delivered?
status == :delivered
end
def cancelled?
status == :cancelled
end
def refunded?
status == :refunded
end
end

RULE #2: DON'T REPEAT YOURSELF (DRY)
▸ Easiest way to refactor
▸ Find duplicates in codes and extract them into a method/class
▸ JUST OPEN YOUR EYES AND READ YOUR CODE AGAIN
▸ Find duplicated patterns in codes and extract them
▸ Find duplicated codes across ﬁles is harder

HATE REFACTORING
😍😍😡😡

RULE #3:
NAMING REVEALS INTENTION

GOOD NAMING IN RUBY/RAILS
▸ Array.ﬁrst, Array.second, Array.third, ..., Array.forty_two
▸ Date.tomorrow, Date.today
▸ 1.hour.ago, 3.weeks.from_now
▸ Array.each

GOOD NAMING?
▸ shopping_cart.total_price
▸ Product.price_less_than(20)
▸ Numerology.calculate_lucky_number_from(dob: user.dob)
▸ person.male?
▸ get_youtube_id(youtube_url)

RULE #3: NAMING REVEALS INTENTION
▸ Naming for variable, method, class, ﬁle, even values
▸ Reveal what you are doing or why you are doing, not how you are doing 
eg. 
(how) UserMailer.use_gmail_smtp_send_email 
(what) UserMailer.send_email 
(why) UserMailer.send_activation_email
▸ The next coder can understand/guess intuitively what your variable/method/
class is doing

describe ProductsController, type: :controller do
describe '#index' do
let!(:p1) { create(:product, published: true) }
let!(:p2) { create(:product, published: false) }
it 'return products' do
get :index
expect(assigns(:products)).to_not include p2
end
end
end

let!(:published_product) { create(:product, published: true) }
let!(:unpublished_product) { create(:product, published: false) }
it 'does not return unpublished products' do
get :index
expect(assigns(:products)).to_not include unpublished_product
end
end
end
let!(:p1) { create(:product, published: true) }
let!(:p2) { create(:product, published: false) }
it 'return products' do
get :index
expect(assigns(:products)).to_not include p2
end
end
end

class User < ActiveRecord::Base
after_create :verify
def verify
UserMailer.verify(self).deliver
end
end

def verify
# send email verification
end
end

after_create :send_email_verification
def send_email_verification
UserMailer.verify_email(self).deliver
end
end
def verify
# send email verification
end
end

RULE #3: NAMING REVEALS INTENTION - THE DON'TS
▸ DON'T DO THIS:
▸ n = 100
▸ p1 = Product.new
▸ product1 = Product.new
▸ category = Product.new
▸ Write comments to explain your code*

RULE #3: NAMING REVEALS INTENTION - THE DOS
▸ Use conventional naming: 
created_at (datetime) vs created_on (date) 
products (array of product) 
published?
▸ Name what the variable/method/class is doing or why it needs to do this
▸ Search in thesaurus.com
▸ Ask a non-coder how to name something or describe what you want to do
▸ Convert comment into a method instead
▸ Ask yourself: How can I let myself understand this code 1 year later?

HATE REFACTORING
😍😍😍😡

RULE #4:
SINGLE RESPONSIBILITY PRINCIPLE

RULE #4: SINGLE RESPONSIBILITY PRINCIPLE (SRP)
▸ Robert C. Martin: "A class should have only one reason to change"
▸ A class or method should only do one thing

class MessagesController < ApplicationController
def create
recipient = User.find(message_params[:recipient])
subject = block_contact_information(message_params[:subject])
body = block_contact_information(message_params[:body])
message = Message.new(recipient, subject, body)
if message.save
render json: {success: "Your message has been sent successfully"}
else
render json: {error: message.errors}
end
end
private
def block_contact_information(content)
phone_regex = /(?:+?|b)[0-9]{4,}/
content.gsub!(phone_regex, '[Blocked Content]')
email_regex = /[a-z]+[a-z0-9_-]*@[a-z0-9_-]+.[a-z]{2,}/i
content.gsub!(email_regex, '[Blocked Content]')
website_regex = /https?://[S]+/
content.gsub!(website_regex, '[Blocked Content]')
end
def message_params
params.require(:message).permit(:receipient, :subject, :body)
end
end

phone_regex = /(?:+?|b)[0-9]{4,}/
end

block_phone_contact(content)
block_email_contact(content)
block_website_contact(content)
end
def block_phone_contact(content)
phone_regex = /(?:+?|b)[0-9]{4,}/
end
def block_email_contact(content)
end
def block_website_contact(content)
end
phone_regex = /(?:+?|b)[0-9]{4,}/
end

class BlockContact
def self.santize(content)
[:phone, :email, :website].inject(content) do |content, contact_type|
self.send("block_#{contact_type}", content)
end
end
def self.block_phone(content)
phone_regex = /(?:+?|b)[0-9]{4,}/
content.gsub(phone_regex, '[Blocked Content]')
end
def self.block_email(content)
content.gsub(email_regex, '[Blocked Content]')
end
def self.block_website(content)
content.gsub(website_regex, '[Blocked Content]')
end
end
# BlockContact.santize('My phone is 91234567 and my email is stevenyap@futureworkz.com')
# => "My phone is [Blocked Content] and my email is [Blocked Content]"

RULE #4: SINGLE RESPONSIBILITY PRINCIPLE (SRP)
▸ Long methods are the easiest to ﬁnd (>10 lines?)
▸ Know the responsibility of Model, View, Controller well
▸ Ask yourself if this object is doing the right thing
▸ Ask yourself if this method is doing only one thing
▸ SRP normally give rise to more advanced refactoring/patterns 
Eg. observer, delegate, services, etc

HATE REFACTORING
😍😍😍😍

USING THE FOUR RULES
▸ Rule #1 of rule #1: 
Always think about test cases ﬁrst!
▸ Refactor using DRY + Naming + SRP iteratively
▸ Think through your code using the 4 rules to achieve a minimum good quality
▸ Don't stop at the 4 rules & learn/refactor more as you gain more experience 
(eg. SOLID principles, LoD, Anti-patterns)

FINAL TIPS ON REFACTORING & FEELING BETTER AS A CODER
▸ Don't stress yourself to refactor the code to be the best 
There are no BEST code in the world
▸ Don't be hard on yourself if you cannot detect a code smell 
Learn from it! You will become better over time!
▸ Take a moment to relish your refactored code! 
Be proud to show it off in the pull request for code review.
▸ Protect your reputation as a world-class coder 
Have pride as a coder!

CLEAN & CLEAR CODE
EASY TO UNDERSTAND

LOVE REFACTORING
😍😍😍😍

4 Simple Rules to Refactoring

Recommended

Recommended

More Related Content

Recently uploaded

Recently uploaded (20)

Featured

Featured (20)

4 Simple Rules to Refactoring