working with legacy code
Post on 22-Oct-2014
4.519 views
DESCRIPTION
Based on Michael C. Feathers book "Working with Legacy Code"TRANSCRIPT
Working with legacy code
Andrea Polci
Legacy code: definition
“source code inherited from someone else and source code inherited from an older version of the software”
(wikipedia)
“code without tests”(Michael Feathers)
Legacy code: caracteristics
● Poor architecture● Stratification of modifications● Non-uniform coding styles● Poor written documentation● “Oral” documentation lost● No tests
● Extremely valuable!● Only successful code become legacy code
Why we have legacy code?
● More and more features● Shortcuts and hacks● Developer rotation● Development team growth
● less communication
Why we need to change legacy code?
● New functionality● Bug● Refactoring● Optimization
Options● Start from scratch?● Look for a new Job?● May be we need
Rambo?● Or Mc Gyver?● May be we need
some “tools” to work effectively with legacy code
Test
● What about legacy code?● To modify it we need
tests● To write test we need
to modify the code
● They gives feedback on changes
● Different kind of tests● Unit● Integration● Functional
An algorithm
1) Identify what to change2) Identify what to test3) Break dependencies4) Write the tests5) Modify and refactoring
What to change
1) Identify what to change● Do we have enough knowledge to choose where
to make changes?● Sometimes we need to modify many different
places just to make a simple change.2) Identify what to test3) Break dependencies4) Write the tests5) Modify and refactoring
I don't understand the code
● Note/Sketching● Listing Markup● Scratch Refactoring● Write tests● Delete Unused Code
● There is the repository for that
I don't understand the structure
● Long lived applications tend to loose structure● It takes long time to understand the big picture● There is no big picture● The team is in emergency mode and lose sight of the
big picture● It's important that every developer understand the
big picture or the code will diverge from the architecture● Tell the story of the system● Naked CRC● Conversation Scrutiny
What to test
1) Identify what to change2) Identify what to test
• Can be an hard work• Effect analisys• How much time do we have?
3) Break dependencies4) Write the tests5) Modify and refactoring
I don't have the time to test
● Be careful!● Sometimes there is no other option● Don't make it worse!
● Try to isolate new (tested) code from legacy code● Sprout method/class● Wrap method/class
Sprout method
public class ProductLablePrinter{ … public void printLabel(int productId) { String barcode; … // compute barcode … // print barcode }}
Sprout method
public class ProductLablePrinter{ … public void printLabel(int productId) { String barcode; … // compute barcode …
logPrinted(barcode); // print barcode }
protected void logBarcode(String barcode) { // My code }
}
Break Dependencies
1) Identify what to change2) Identify what to test3) Break dependencies
● How do I put a class in a test harness?● How I know I'm not breaking anything?
4) Write the tests5) Modify and refactoring
Sensing & Separation
● Sensing:we break dependencies to sense when we can't access values our code computes
● Separation:we break dependencies to separate when we can't even get a piece of code into a test harness to run
Sensing & Separation: Example
public class ProductLablePrinter{ … Public void printBarcode(int productId) { String barcode; … // compute barcode … // print barcode; }}
Seam
● Seam:a place where you can alter behavior of your program without editing in that place
● Enabling Point:Every seam has an enabling point, a place where you can make the decision to use one behaviour or another
● Looking for existings seams in legacy code allow us to break dependencies (for sensing or separation) without refactoring.
Different kind of Seams
● Preprocessor seams
● Link seam
● Object seam
Object seam: Examplepublic class ProductLablePrinter{ … public void printLabel(int productId) { String barcode; … // compute barcode … printBarcode(barcode); }
protected void printBarcode(String barcode) { // access to printer }}
Public void testPrintBarcode() { ProductLablePrinter plp = new ProductLabelPrinter(){ String lastPrinted = null; protected void printBarcode(String barcode) {lastPrinted=barcode;} }
// … test code}
I can't get this class into a Test
● Objects of the class can't be created easily● Parameters we have to pass to the constructor● Hidden dependencies
● The test harness won't easily build with the class in it
● The constructor we need to use has bad side effects
● Significant work happens in the constructor and we need to sense it
Example (1)public void testLabelPrinter() { new LabelPrinter();}
The constructor LabelPrinter is undefined
Example (2)public class LabelPrinter { public LabelPrinter(Printer prn, Warehose wh) { … this.printer = prn; if(!this.printer.isOnline()) { throw new … } }}
public void testLabelPrinter() { Printer prn = new Printer(“stampante”); Warehouse wh = new Warehouse(“magazzino1”); LabelPrinter labPrint = new LabelPrinter(prn, wh);}
public class Printer { boolean isOnline(){ … } void startJob() { … } void printLine(String line) { … } void endJob() { … }}
Example (3)
public interface PrinterInterface { boolean isOnline(); void startJob(); void printLine(String line); void endJob();}public class Printer implements PrinterInterface { …}public class LabelPrinter { public LabelPrinter(PrinterInterface prn, Warehose wh) { ... }}
I can't run this method in a test
● Method not accessible to the test● It's hard to construct the parameters● Side effects (database, access to
hardware, ecc.)● Need to sense through objects used by the
method
Test
1) Identify what to change2) Identify what to test3) Break dependencies4) Write the tests5) Modify and refactoring
Modify and refactoring
1) Identify what to change2) Identify what to test3) Break dependencies4) Write the tests5) Modify and refactoring
● TDD● Programming by difference
Making changes takes too much time
● Understanding● How can we increase our understanding of the code?
● Lag Time● It takes to much time to see the effect of changes and
this slow down the development● Built time● Slow tests● No unit tests● Often to solve this we need to break dependecies
Tools
● Authomatic refactoring tools● Can we trust them?
● Mock Objects● Unit test harnesses
● JUnit● Other test harnesses
● Non-unit tests
Conclusions
● No “silver bullet” here● It's an hard work but (usually) not
impossible● At first it will seems overwhelming, but
things will get better as the number of tests increase
● Be pragmatic!
Questions?
References
● Workking Effectively with Legacy Code,Michael C. Feathers
● Joel on Software: Things you should never do, part I
http://www.joelonsoftware.com/articles/fog0000000069.html
● Michael Dubakov: Refactoring vs Rewritehttp://www.targetprocess.com/blog/2009/11/refactoring-vs-rewrite.html