Refactoring Big Design Smells : Presented by Sanjay Kumar

© 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

SunjayKumar@gmail.comLinkedIn.com/in/sunjaykumarTwitter.com/AgilityDelivers