© 2015 iZenBridge | Public
Refactoring Strategy for
Big Design Smells
© 2015 iZenBridge | Public
Speaker Introduction – Sanjay Kumar
• Trainer with iZenBridge Consultancy:• Certified Scrum Developer (CSD)
• Agile Certified Practitioner (PMI-ACP)
• Corporate trainings on Agile, Scrum, XP, Kanban
• 15+ years of software development experience• Companies – TCS, Actuate, Keane, Deutsche Bank, et al
• Roles – Developer, Consultant, Tech Lead, Manager, Scrum Master
• Team Settings – Local, Global, Big, Small and Silo
• Technologies – Java/J2EE, PL/SQL
• Experience with Agile – 2006 onwards
• Agile Certifications – CSM, CSD, CSP, PMI-ACP, SAFe Agilist
© 2015 iZenBridge | Public
Session Agenda
What is Good Design?
Common Code Smells
Problem with Big Methods
When to Refactor?
Challenges for refactoring
Refactoring Strategy
Refactoring Example
© 2015 iZenBridge | Public
What is Good Design?
© 2015 iZenBridge | Public
Defining a Good Quality Software
© 2015 iZenBridge | Public
Features of Good Design
Functional
Maintainable
Testable
Efficient/Performant
Scalable
Mandatory
Proactive
Adaptive
© 2015 iZenBridge | Public
Symptoms of Poor Design?
© 2015 iZenBridge | Public
Symptoms of Poor Design
Rigidity
Fragility
Immobility
Opacity
Needless Complexity
Needless Repetition
© 2015 iZenBridge | Public
Code Smells
Commonly used bad practices that make a system inefficient and difficult to maintain:
Long method Large class
Duplicate code Inappropriate Intimacy
Poorly written comments Obsolete or commented-out code
Feature envy Improper naming
Obsolete comments Shotgun surgery
Pure Data class Long parameter list
Switch statements Parallel inheritance hierarchies
Divergent change Speculative Generality
© 2015 iZenBridge | Public
Big Methods – Why a Code Smell?
An example of Non-modular code that break “Single Responsibility
Principle”, with following side effects:
Difficult to read
Immobile Difficult to reuse embedded logic/algorithm
Contain Duplicated code
Difficult to test More permutations and combinations
© 2015 iZenBridge | Public
When could a Method be Too BIG?
More than 10 lineso 20 lines is definitely Big
Performs multiple steps in a process, all by itself
Has blocks of code that do one unique thing:o Complex conditions
o Embedded algorithms
o Complex calculations
© 2015 iZenBridge | Public
Example – Cost Calculation
public static double someMethod(Date date1, Date date2)
{ int diff = (int) Math.ceil(
(date2.getTime() – date1.getTime())/86400000);
double total = 0; if (date2.before(StartDate) || date1.after(EndDate)) total = 5000 * diff; else total = 10000 * diff;
return (1.175) * total;}
What does this code do?
© 2015 iZenBridge | Public
Example – Cost of Hotel Stay
Does this read any better?public static double getHotelCharge
(Date startDate, Date endDate) { int tripDuration = (int) Math.ceil(
(endDate.getTime() - startDate.getTime())/86400000);
double hotelCharge = 0; if (endDate.before(peakSeasonStart) || startDate.after(peakSeasonEnd)) hotelCharge = 5000 * tripDuration; // off season rate else hotelCharge = 10000 * tripDuration; // peak season rate
return (1 + totalTaxRate) * hotelCharge;}
Can this be improved further?
© 2015 iZenBridge | Public
Refactoring Guidelines
© 2015 iZenBridge | Public
When to Refactor?
1. There is an obvious scope of improvement
o Code smells
o Operational inefficiency
2. You happen to touch the code
o Need to add new functionality
o Need to fix a bug
o A technical story for refactoring
3. Your changes will be tested thoroughly
© 2015 iZenBridge | Public
Challenges for Refactoring
1. Lack of understanding
2. Lack of time
3. Lack of motivation – complacency or inertia
4. High cost of breaking the code
© 2015 iZenBridge | Public
If you MUST Refactor…
RULE #1
Make sure you DON’T BREAK the code!!
© 2015 iZenBridge | Public
Refactoring Process
1. Understand the code
• Must refactor someone else’s code only after you have understood it well
enough.
2. Ensure good test coverage for existing code
• If there aren’t enough automated tests, create them.
3. Change incrementally, validating at each step
4. Once done, make sure it runs through normal testing process
before deployment (QA, UAT, etc.)
© 2015 iZenBridge | Public
Exercise
Time to soil our hands!
© 2015 iZenBridge | Public
Refactoring Step 1
Understand the Code…
© 2015 iZenBridge | Public
Refactoring Step 2
Ensure good test coverage for existing code…
© 2015 iZenBridge | Public
Refactoring Step 3
Change incrementally, validating at each step…
© 2015 iZenBridge | Public
© 2015 iZenBridge | Public
Stay Connected
iZenBridge Consultancyhttp://www.iZenBridge.comhttp://forum.iZenBridge.com
http://www.youtube.com/izenbridge
Discuss Agile Network http://www.DiscussAgile.com
https://www.linkedin.com/grp/home?gid=8327124
[email protected]/in/sunjaykumarTwitter.com/AgilityDelivers