• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Working With Legacy Code
 

Working With Legacy Code

on

  • 4,252 views

Based on Michael C. Feathers book "Working with Legacy Code"

Based on Michael C. Feathers book "Working with Legacy Code"

Statistics

Views

Total Views
4,252
Views on SlideShare
4,249
Embed Views
3

Actions

Likes
7
Downloads
91
Comments
0

2 Embeds 3

http://www.slideshare.net 2
https://duckduckgo.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Working With Legacy Code Working With Legacy Code Presentation 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 ● They gives feedback ● What about legacy on changes code? ● Different kind of tests ● To modify it we need tests ● Unit ● To write test we need ● Integration to modify the code ● Functional
    • An algorithm 1) Identify what to change 2) Identify what to test 3) Break dependencies 4) Write the tests 5) 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 test 3) Break dependencies 4) Write the tests 5) 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 change 2) Identify what to test • Can be an hard work • Effect analisys • How much time do we have? 3) Break dependencies 4) Write the tests 5) 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 change 2) Identify what to test 3) Break dependencies ● How do I put a class in a test harness? ● How I know I'm not breaking anything? 4) Write the tests 5) 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: Example public 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 change 2) Identify what to test 3) Break dependencies 4) Write the tests 5) Modify and refactoring
    • Modify and refactoring 1) Identify what to change 2) Identify what to test 3) Break dependencies 4) Write the tests 5) 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 Rewrite http://www.targetprocess.com/blog/2009/11/refactoring-vs-rewrite.html