The code around us is imperfect, we all know it. Should we still thrive to make it better and take responsibility for the change without fear? In his presentation, Antoni Rasul tries to reason on this dilemma, identify typical design smells, evaluate pros and cons and show some practical ways of dealing with them by adopting continuous refactoring and responsible approach to development. This presentation by Antoni Rasul (Lead Software Engineer, GlobalLogic) was delivered at GlobalLogic Java Conference #2 in Krakow on April 23, 2016.

1. Code and design smells.
Are they a real threat?
Antoni Rasul

2. Lehman's laws of software evolution
• Originally formulated by Manny Lehman in 1974 and later
refined, as a result of empirical study within IBM
• Aimed at finding scientific properties of evolution of
different classes of software
• System types:
• S-type (specified) Systems
• P-type (problem solving) Systems
• E-type (evolutionary) Systems

3. E-type Systems laws of evolution (since 1996)
I. Continuing Change
II. Increasing Complexity
III. Self Regulation
IV. Conservation of Organizational Stability
V. Conservation of Familiarity
VI. Continuing Growth
VII. Declining Quality
VIII.Feedback System

4. Technical debt
• Monetary metaphor
• Impossible to measure precisely
• If not repaid regularly – accumulates interest
Time
Effort
Interest
payment
Feature

5. Warning signs of rising debt
• The quality of your software is degrading
• The bug backlog is increasing
• The bug threshold in release is rising
• Your productivity is slipping
• Fictional deadlines
• The team members don't care

6. Effective ways to reduce the debt
• Define the debt
• Revise the Definition of Done
• Testing tasks part of story
• Done means code cleaned, refactored, deployed and tested
• Use tools like Sonar to visualise (also for management)
• Refactor
• Identify code smells and plan for change
• Automate

7. Refactoring
• Refactoring: a change made to the internal structure of
software to make it easier to understand and cheaper to
modify without changing its observable behavior.
• Refactor when:
• Adding a function
• Fixing a bug
• Doing a code review
• Perform larger refactorings in small increments

8. Code smells
• Duplicated Code
• Shotgun surgery
• Feature envy
• Switch statements
• Refused bequest
• Telescoping constructors
• Big Ball of Mud

9. Techniques
• Extract method/class
• Substitute algorithm
• Introduce parameter object
• Replace type conditional with Polymorphism/Strategy
• Fluent interface with Essence pattern

10. Duplicated Code or Structure
• In same class
 Extract Method
• In sibling classes
 Extract Method
 Pull method Up
• In unrelated classes
 Substitute algorithm
 Extract Class
 Use extracted class in other places

11. Shotgun surgery
• Adding simple feature requires small changes in gazillion
classes
• Difficult to eliminate in big systems
• Removing duplicates first – reduces the smell
• Code generation tools help reduce the problem further

12. Feature envy
• One class’s method is extensively using data and methods
of another class
• Usually easy to spot and fix – move the method to the class
where it belongs
• If method uses several classes – move it to the one with
most used data
• Use Move Method, possibly with Extract Method

13. Switch by type in multiple places - problem
public class PriceCalculator {
public double calculatePrice(Customer customer, Car car, Period period) {
double tax = 0;
double discount = 0;
switch(customer.getType()) {
case REGULAR:
discount = 0;
tax = 0.2;
case BUSINESS:
discount = 0.5;
tax = 0.2;
case BIG_BUSINESS:
discount = 0.2;
tax = 0.1;
}
return period.getDays() * car.getDayPrice() * (1 - discount * tax);
}
}

14. Switch by type - Replace type code by
polymorphism
public interface Customer {
CustomerType getType();
}
public interface CustomerType {
double getDiscount();
double getTax();
}
public class RegularCustomer implements CustomerType {
...
}
public class BusinessCustomer implements CustomerType {
...
}
public class BigBusinessCustomer implements CustomerType {
...
}

15. Switch by type - refactored
public class PriceCalculator {
public double calculatePrice(Customer customer, Car car, Period period) {
final double tax = customer.getType().getTax();
final double discount = customer.getType().getDiscount();
return period.getDays() * car.getDayPrice() * (1 - discount * tax);
}
}
• If price calculation algorithm would depend on Customer type –
use Strategy

16. Refused bequest
public interface Car {
String getModel();
double getDayPrice();
}
public class Truck implements Car {
public String getMaxCargoVolume(){...};
}
public class CarFleet implements Car {
private List<Car> cars;
public String getModel() {
return null; // Hmmmmm Let's return null here 
}
public double getDayPrice() {
return this.cars.stream().mapToDouble(c -> c.getDayPrice()).sum();
}
}
• When subclass inherits data/methods that it doesn’t want
• When sublcass refuses to meaningfully implement all interface methods

17. Refused bequest - ideas
• Hierarchy is wrong
• Reshuffle hierarchy, so that parent contains only what’s common
• Another solution – pull the violating class out of the hierarchy and
use a delegate to the instance of (former) parent class

18. Refused bequest – example refactored
public interface RentableItem {
double getDayPrice();
}
public interface Car extends RentableItem {
String getModel();
}
public interface CarFleet extends RentableItem {
double getFleetDiscount();
}
public class StandardFleet implements CarFleet {
private List<Car> cars;
public double getDayPrice() {
return this.cars.stream().mapToDouble(c -> c.getDayPrice()).sum();
}
public double getFleetDiscount() {
return 0.1;
}
}

19. Telescoping constructors
public class RentalContract {
...
public RentalContract(Customer cust, List<Car> cars, Date startDate) {
this(cust, car, startDate, null);
}
public RentalContract(Customer cust, List<Car> cars, Date startDate, Date endDate) {
this(cust, cars, null, null, startDate, endDate);
}
public RentalContract(Customer customer, List<Car> cars, BigDecimal extraDiscount,
String description, Date startDate, Date endDate) {
this.customer = customer;
this.cars = cars;
this.extraDiscount = extraDiscount;
this.description = description;
this.startDate = startDate;
this.endDate = endDate;
}
...
}

20. Telescoping constructors – required fields
public RentalContract(
Customer customer,
List<Car> cars,
BigDecimal extraDiscount,
String description,
Date startDate,
Date endDate)
{...}
• Instantiating is cumbersome, error-prone
• Optional fields are mixed with required ones

21. Telescoping constructors – refactoring ideas
• Introduce parameter object from startDate and endDate
public class DateRange {
private Date start;
private Date end;
...
public DateRange withStart(Date start) {
this.start = start;
return this;
}
public DateRange withEnd(Date end) {
this.end = end;
return this;
}
}
• Use Essence pattern composed of:
• Builder
• Fluent interface
• Validation of required fields before object construction

22. Telescoping constructors – fluent builder
public class RentalContractBuilder {
...
public RentalContractBuilder withCustomer(Customer customer) {
this.customer = customer;
return this;
}
public RentalContractBuilder addCar(Car car) {
cars.add(car);
return this;
}
public RentalContractBuilder withCars(List<Car> cars) {
this.cars = cars;
return this;
}
public RentalContractBuilder withDateRange(DateRange dateRange) {
this.dateRange = dateRange;
return this;
}
public void validate() {
customerValidator.validate(customer);
carValidator.validate(cars);
datesValidator.validate(dateRange);
}
public RentalContract build() {
validate();
return new RentalContract(this);
}
}

23. Telescoping constructors – end result
public class RentalContract {
...
RentalContract(RentalContractBuilder contractBuilder) {
this.customer = contractBuilder.getCustomer();
this.cars = contractBuilder.getCars();
this.dateRange = contractBuilder.getDateRange();
}
}
RentalContract rentalContract = new RentalContractBuilder()
.withCustomer(customer)
.addCar(mustang)
.addCar(camaro)
.withDateRange(new DateRange().withStart(new Date()))
.build();
• Constructor with default access
• We are sure that rentalContract is a valid instance after build()

24. Big Ball of Mud – The Mikado Method
• Allows for systematic reshaping of the system
• Easy to use
• Provides stability to the codebase while changing it
• Fits in an incremental process
• Scalable, the whole team can participate

25. The Mikado Method
• Set a goal
• Experiment
• Visualize
• Undo

26. The Mikado Method - flow
Draw goal
Implement goal
naively
Errors?
Come up with immediate
solutions and draw them as
sub-goals
Revert changes
Select next goal
Yes
No Change
makes sense?
Check in !
All goals
completed?
Done!
Yes
Yes
Yes
No
No

27. Mikado graph
Mikado
Goal
Prerequisite:
immediate
solution
Another
prerequisite
More
prerequisites ..linked to
previous
Can have
common
dependencies

28. Summary
• Forgive the predecessors
• Take small steps
• Work as a team
• Convince management
• Willingness to change