The document discusses techniques for improving the quality of existing software, including reducing technical debt, following principles like DRY and SOLID, using characterization tests to preserve behavior during refactoring, and improving skills to write higher quality code faster. It covers topics like refactoring, test-driven development, dependency inversion, and design patterns. The goal is to maintain and enhance application code quality over time through refactoring and preventing technical debt.

1. Improving the Quality of
Existing Software
Steve Smith
Founder, DevIQ
@ardalis | ardalis.com

2. Please Share
• LiveTweeting and Photos are encouraged
• Questions and Feedback via Social Media are welcome
• Use #StirTrek and/or #ImproveSoftware

3. Pluralsight – FreeTokens
I have some 1-month free
passes; see me after if
you’d like one

4. Software Rots

6. Technical Debt
• Low quality code and shortcuts in our applications
• Technical debt, like real debt, has direct cost to pay off as well as interest

7. http://www.jimhighsmith.com/

8. Preventive Maintenance
• Refactoring
• Eliminate Duplication
• Simplify Design
• AutomatedTests
• Verify correctness
• Avoid regressions
• Increase Confidence

9. When should you refactor?
• While delivering value

10. “
”
You don’t need permission to practice basic hygiene
when you write software.
http://ardalis.com/when-should-you-refactor/
Make cleaning up your code something you do as part of writing code.

12. Refactoring Should Not Change System
Behavior

13. The Refactoring Process
• Verify existing behavior
• Write CharacterizationTests if none exist
• Find test points
• Break dependencies
• Apply Refactoring
• Confirm existing behavior is preserved

14. CharacterizationTests
Process
1. Write a test you know will fail
2. Use the output of the failing test to determine the existing behavior to
assert
3. Update the test with the new value/behavior
4. Run the test again – it should now pass

16. S O L I DPrinciples
http://flickr.com/photos/kevinkemmerer/2772526725/

17. Principles of OO Design
0. Don’t RepeatYourself (DRY)
1. Single Responsibility
2. Open/Closed
3. Liskov Substitution
4. Interface Segregation
5. Dependency Inversion

20. Don’t Repeat
RepeatYourself
• Duplication in logic calls for abstraction
• Duplication in process calls for automation

21. Common Refactorings
• Replace Magic Number/String
• Parameterize Method
• Pull Up Field
• Pull Up Method
• Replace Conditional With Polymorphism
• Introduce Method

22. Common Source of Repetition: Role Checks
if(user.IsInRole(“Admins”)
{
// allow access to resource
}
// favor privileges over role checks
// ardalis.com/Favor-Privileges-over-Role-Checks
var priv = new ContentPrivilege(user, article);
if(priv.CanEdit())
{
// allow access
}

23. Visual Studio Code Clones
• Find similar blocks of code in your projects/solution
• Can detect matches that are similar but vary in small ways (like variable
names)
• Available inVS2015 Premium and Ultimate

25. Single Responsibility Principle
The Single Responsibility Principle states that every object should have a single
responsibility, and that responsibility should be entirely encapsulated by the
class.
Wikipedia
There should never be more than one reason for a class to change.
Robert C. “Uncle Bob” Martin

26. What is a responsibility?
“My CustomerManager class is only responsible for
anything to do with a Customer.That follows SRP, right?”

27. Examples of Responsibilities
• Persistence
• Validation
• Notification
• Error Handling
• Logging
• Class Selection / Construction
• Formatting
• Parsing
• Mapping

28. Dependency and Coupling
• Excessive coupling makes changing legacy software difficult
• Breaking apart responsibilities and dependencies is a large part of working
with existing code

29. Common Refactorings
• Extract Class
• Extract Method
• Move Method

30. Heuristics and Code Smells
• Visual Studio Metrics

31. Cyclomatic Complexity
https://en.wikipedia.org/wiki/Cyclomatic_complexity

32. Keep
Cyclomatic Complexity
under 10
for every method

34. Code Smell: Regions
More on Regions: http://ardalis.com/regional-differences

36. Open / Closed Principle
The Open / Closed Principle states that software entities (classes, modules,
functions, etc.) should be open for extension, but closed for modification.
Wikipedia

37. Open / Closed Principle
Open to Extension
New behavior can be added in the future
Closed to Modification
Changes to source or binary code are not required
Dr. Bertrand Meyer originated the OCP term in his 1988 book, ObjectOrientedSoftwareConstruction

38. Common Refactorings
• Extract Interface / Apply Strategy Pattern
• Parameterize Method
• FormTemplate Method

39. OCP Fail

40. OCP OK

41. OCP Fail
public bool IsSpecialCustomer(Customer c)
{
if(c.Country == “US” && c.Balance < 50) return false;
if(c.Country == “DE” && c.Balance < 25) return false;
if(c.Country == “UK” && c.Balance < 35) return false;
if(c.Country == “FR” && c.Balance < 27) return false;
if(c.Country == “BG” && c.Balance < 29) return false;
if(c.Age < 18 || c.Age > 65) return false;
if(c.Income < 50000 && c.Age < 30) return false;
return true;
}

42. OCP OK
private IEnumerable<ICustomerRule> _rules;
public bool IsSpecialCustomer(Customer customer)
{
foreach(var rule in _rules)
{
if(rule.Evaluate(customer) == false) return false;
}
return true;
}

44. Liskov Substitution Principle
The Liskov Substitution Principle states that Subtypes must be substitutable for
their base types.
Agile Principles, Patterns, and Practices in C#
Named for Barbara Liskov, who first described the principle in 1988.

45. Common Refactorings
• Collapse Hierarchy
• Pull Up / Push Down Field
• Pull Up / Push Down Method

46. Liskov Substitution Fail
foreach(var employee in employees)
{
if(employee is Manager)
{
Helpers.PrintManager(employee as Manager);
break;
}
Helpers.PrintEmployee(employee);
}

47. Liskov Substitution OK
foreach(var employee in employees)
{
employee.Print();
// or
Helpers.PrintEmployee(employee);
}

48. Nulls Break Polymorphism
foreach(var employee in employees)
{
if(employee == null)
{
// print not found message
break;
}
Helpers.PrintEmployee(employee);
} http://ardalis.com/nulls-break-polymorphism

50. Interface Segregation Principle
The Interface Segregation Principle states that Clients should not be
forced to depend on methods they do not use.
Agile Principles, Patterns, and Practices in C#
Corollary:
Prefer small, cohesive interfaces to “fat” interfaces

51. Common Refactorings
• Extract Interface

52. Keep Interfaces Small and Focused

53. Membership Provider

54. ISP Fail (sometimes)
public IRepository<T>
{
T GetById(int id);
IEnumerable<T> List();
void Create(T item);
void Update(T item);
void Delete(T item);
}

55. ISP OK (i.e. to support CQRS)
public IRepository<T> : IReadRepository<T>,
IWriteRepository<T>
{ }
public IReadRepository<T>
{
T GetById(int id);
IEnumerable<T> List();
}
public IWriteRepository<T>
void Create(T item);
void Update(T item);
void Delete(T item);
}
Existing implementations of
IRepository<T> are
unaffected by pulling out
smaller interfaces!
No existing code breaks!

57. Dependency Inversion Principle
High-level modules should not depend on low-level modules. Both
should depend on abstractions.
Abstractions should not depend on details. Details should depend on
abstractions.
Agile Principles, Patterns, and Practices in C#

58. Dependency Inversion Principle
• Depend on Abstractions
• Interfaces, not concrete types
• Inject Dependencies into Classes
• Structure Solution so Dependencies FlowToward Core
• Onion Architecture (a.k.a. Ports and Adapters, a.k.a. Hexagonal Architecture)

59. Application Layers

60. Data Access Evolution
No separation of concerns:
 Data access logic baked directly into UI
ASP.NET Data Source Controls
Classic ASP scripts
 Data access logic in UI layer via codebehind
ASP.NET Page_Load event
ASP.NET Button_Click event
User Interface
Database
Compile Time
Runtime

61. Data Access : Helper Classes
 Calls to data made through a utility
 Example: Data Access Application Block
(SqlHelper)
 Logic may still live in UI layer
 Or a Business Logic Layer may make calls to a
Data Access Layer which might then call the helper
User Interface
Database
Compile Time
Runtime
Helper Class

62. What’s Missing? Abstraction!
 No way to abstract away data
access
 Tight coupling
 Leads to Big Ball of Mud
system
 Solution:
Depend on interfaces, not
concrete implementations
What should we call such
interfaces? Repositories!
User Interface
Database
Compile Time
Runtime
Core
IFooRepository
Infrastructure
SqlFooRepository

63. DIP Architecture (aka Ports and Adapters)

64. Common Dependencies
• Framework
• Third Party Libraries
• Database
• File System
• Email
• Web Services
• System Resources (Clock)
• Configuration
• The new Keyword
• Static methods
• Thread.Sleep
• Random
See also responsibilities:
• Persistence
• Validation
• Notification
• Error Handling
• Logging
• Class Selection /
Construction
• Formatting
• Parsing
• Mapping

65. Common Refactorings
• Extract Class
• Extract Interface / Apply Strategy Pattern
• Extract Method
• Introduce Service Locator / Container

66. DIP Fail

67. Hidden Dependencies
• Checkout Depends on an available SMTP server, but the class doesn’t reflect
this
• Follow the Explicit Dependencies Principle
• http://deviq.com/explicit-dependencies-principle/

68. Some Improvement (Façade)

69. DIP OK (Strategy Pattern / DI)

70. DIP OK (Strategy Pattern / DI)

71. Improving Quality Across the Industry

73. Self-Improvement and Quality
• How fast can you produce:
• Code you believe to be of high quality
• Code that maybe gets the job done, but you believe to be of low quality
• Which one can you produce more quickly?
• Why?
• How can we develop our skills and our tools so that building quality is
natural and easier than not doing so?

74. 0
2
4
6
8
10
12
14
16
Week 1 Week 2 Week 3 Week 4 Week 5 Week 6 Week 7 Week 8 Week 9
User Stories Completed
High Quality Low Quality

75. 0
2
4
6
8
10
12
14
16
18
20
Week 1 Week 2 Week 3 Week 4 Week 5 Week 6 Week 7 Week 8 Week 9
User Stories Completed
High Quality Low Quality

76. Summary
•Maintain / Improve Application Code
•Follow DRY/SOLID Principles
•Use CharacterizationTests to “fix” behavior
•Apply Common Refactorings
•Re-runTestsAfter (and during) Refactorings
•Be Explicit About Class Dependencies
•Train and Practice toWrite Better Code Faster

77. Learn More
• DevIQ.com
• Ardalis.com
• Twitter: @ardalis
• Pluralsight:
• SOLID Principles of OO Design
• N-TierArchitecture in C#
• Refactoring Fundamentals
• Domain-Driven Design Fundamentals
• Design Pattern Library
• Pair Programming

78. Books
 Refactoring http://amzn.to/110tscA
 Refactoring to Patterns http://amzn.to/Vq5Rj2
 Working Effectively with Legacy Code http://amzn.to/VFFYbn
 Code Complete http://amzn.to/Vq5YLv
 Clean Code http://amzn.to/YjUDI0