12. 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?
16. 4 SIMPLE RULES TO REFACTORING BY STEVEN YAP
THE FOUR RULES
▸ Write Test Cases
▸ Don't Repeat Yourself (DRY)
▸ Naming Reveals Intention
▸ Single Responsibility Principle (SRP)
18. 4 SIMPLE RULES TO REFACTORING BY STEVEN YAP
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
27. 4 SIMPLE RULES TO REFACTORING BY STEVEN YAP
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 files is harder
31. 4 SIMPLE RULES TO REFACTORING BY STEVEN YAP
GOOD NAMING IN RUBY/RAILS
▸ Array.first, Array.second, Array.third, ..., Array.forty_two
▸ Date.tomorrow, Date.today
▸ 1.hour.ago, 3.weeks.from_now
▸ Array.each
32. 4 SIMPLE RULES TO REFACTORING BY STEVEN YAP
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)
33. 4 SIMPLE RULES TO REFACTORING BY STEVEN YAP
RULE #3: NAMING REVEALS INTENTION
▸ Naming for variable, method, class, file, 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
39. 4 SIMPLE RULES TO REFACTORING BY STEVEN YAP
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*
40. 4 SIMPLE RULES TO REFACTORING BY STEVEN YAP
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?
44. 4 SIMPLE RULES TO REFACTORING BY STEVEN YAP
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
49. 4 SIMPLE RULES TO REFACTORING BY STEVEN YAP
RULE #4: SINGLE RESPONSIBILITY PRINCIPLE (SRP)
▸ Long methods are the easiest to find (>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
53. 4 SIMPLE RULES TO REFACTORING BY STEVEN YAP
USING THE FOUR RULES
▸ Rule #1 of rule #1:
Always think about test cases first!
▸ 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)
54. 4 SIMPLE RULES TO REFACTORING BY STEVEN YAP
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!