Taming the Monster Legacy Code Beast

Taming Legacy Code Monsters

*
Caleb
* I’m here to help.

Last year
10Reasons yoursoftwareSucks
(and the 10 practicesto fix it)

Building teams that engineer better software
Development ∙ Team Work ∙ Process

back to…
Taming Legacy Code Monsters

Definition “Legacy”
n. Software that I’m afraid to maintain, extend, or change it actually scares me to touch that code.

What’s the differencebetween an application and

Legacy Monster

Legacy Monster
Processor
Static Config
Static Proxy
Processor Settings
Data Connections
Rules Configurations
Coupling
Coupling
Coupling
Coupling
Coupling
Rules
Data
Coupling

Legacy Monster
Solution contained over 68 projects.
Most of which were notused.
No horizontal layers.
Required IIS 6 / legacy URL rewriter / 32 bit C Lib / IIS Rules export/import / Database Connections / Proper Configuration X 3
To run or test ANY part on a dev box…

Strategy #1
Know your Foe

Strategy #1
nDepend

Strategy #1
Visual Studio Dependency Graph

Strategy #1
Demo
Using theVisual Studio Dependency Graph

Strategy #1
Demo
Pro tip:Look for big blobs& thick linesto concrete types

Strategy #2
Create aSafety Net

Source Control+ Test
Strategy #2

Strategy #2
Source Control+ Test

Strategy #2
Source Control

// source
// svn / git / tfs ..
// r1.1
// r1
// r2
// r3
// trunk
// trunk
Branching for FUN!
//

Strategy #2
Unit TestsIntegration
Regression
Load Tests
Etc…
Tests

Isolation and White box Unit Testing for .NET
Demo: Safety Net
Legacy Monster
“Pexautomatically generates test suites with high code coverage.…[and] finds interesting input-output values of your methods, which you can save as a small test suite with high code coverage. Microsoft Pex is a Visual Studio add-in for testing .NET Framework applications.”
Processor
Static Config
Static IProxy
Processor Settings
Data Connections
http://research.microsoft.com/en-us/projects/pex/
Rules
Data

what about hard to test code?
refactoring testability

privateIList<Bean> goodBeans { get; set;}
privateIList<Bean> badBeans { get; set;}
publicvoidAddBean(Bean bean){
if(bean.size > 10)
goodBeans.Add(bean);
else
badBeans.Add(bean);
}
publicvoidUpdateBeans(){
BeanData.Update(goodBeans);
goodBeans.Clear();
badBeans.Clear();
}

1
Clearly an arbitrary example
Does represent actual production code that I have worked with
2
3
AddBean(b); AddBean(b), UpdateBeans();
Usage scenario is
How can we test the AddBean() Logic?

publicIList<Bean> GoodBeans{ get; private set;}
privateIlist <Bean>badBeans{ get; set;}
if(bean.size > 10)
GoodBeans.Add(bean);
else
badBeans.Add(bean);
}
GoodBeans.Clear();
badBeans.Clear();
}
privateIList<Bean> goodBeans { get; set;}
privateIList<Bean> badBeans { get; set;}
if(bean.size > 10)
goodBeans.Add(bean);
else
badBeans.Add(bean);
}
goodBeans.Clear();
badBeans.Clear();
}
A: create a readonlyaccessor to “sense” thegoodBean state externally

What about the UpdateBeans() method?
goodBeans.Clear();
badBeans.Clear();
}
goodBeans.Clear();
badBeans.Clear();
if (OnBeansUpdate != null)
OnBeansUpdate();
}
publiceventActionOnBeansUpdate;

Code Coverage + Continuous Integration
Not a silver bullet
still need to make sure that we are testing “the right” things, and not just hitting some magical number
still need to make sure we have healthy tests
Pro tip

Creates a base line or smoke test to look for
Watch trends over magic percent numbers
Pro tip

Team City Code Coverage

Sonar

Strategy #3

Strategy #3
Divide and Conquer
(pick your battles)

36
Commitment

37
Raise your hand and repeat after me,
Commitment

38
Raise your hand and repeat after me,
Commitment
I will not practice bad code.

“Resist Legacy Coupling”

“Resist Legacy Coupling”
tight coupling = change anywhereaffects everything
Legacy Monster
Processor
Static Config
Static Proxy
Processor Settings
Data Connections
New Functionality
Coupling
Needs IProxy
Coupling
static Config class leads to Heavy Weight testing
Coupling
Coupling
Coupling
Rules
Data
don’t reference Config Monster
Coupling
use DI for only what you need (IProxy)

Introduce SOLID principals on new development… gradually improve code over time
http://developingux.com/di/

wrap up

Know your Foe
wrap up
Use a Safety Net
Divide and Conquer

Thank you!
Proaction
MentorS
@calebjenkins
http://developingux.com
@proactionmentor
caleb@proactionmentors.com

Photo Credits
© Michael Cummings - http://dreaminpictures.com
http://www.flickr.com/photos/boogeyman13/2432667459/
http://www.flickr.com/photos/stopthegears/50553611/
http://www.flickr.com/photos/pochateca/324414459
http://www.flickr.com/photos/27620885@N02/2594362917

http://www.flickr.com/photos/27620885@N02/2594363003
http://www.flickr.com/photos/flyingturtle/3976070342/
http://www.flickr.com/photos/jfravel/1001472806/
http://www.flickr.com/photos/flyingturtle/3976076272/
http://www.lostechies.com/blogs/derickbailey/archive/2009/02/11/solid-development-principles-in-motivational-pictures.aspx

http://developingux.com	256
http://agile.dzone.com	4
http://mobile.dzone.com	4
http://feeds.feedburner.com	3
http://www.slideshare.net	1

Taming the Monster Legacy Code Beast

by Caleb Jenkins on Jul 17, 2011

Accessibility

Categories

Tags

Upload Details

Usage Rights

5 Embeds 268

Statistics

Taming the Monster Legacy Code Beast — Presentation Transcript