• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Working Effectively with Legacy Code
 

Working Effectively with Legacy Code

on

  • 5,033 views

Book review: Working Effectively with Legacy Code, by Michael C. Feathers ...

Book review: Working Effectively with Legacy Code, by Michael C. Feathers

Agenda
- The mechanics of change
- Changing software
- Dependency breaking techniques

This session is for developers who need to work on code projects that where written without good unit-testing.

Statistics

Views

Total Views
5,033
Views on SlideShare
5,028
Embed Views
5

Actions

Likes
6
Downloads
75
Comments
0

1 Embed 5

http://www.slideshare.net 5

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

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
  • Adding a feature or fixing a bug: Behavior is the most important thing about software. It is what usres depend on. Users like it when we add new behavior (provided it is what the really wanted), but if we change or remove behavior they depend on (introduce bugs), they stop trusting us.Refactoring: Make changes without changing he behavior. Make software more maintainable. It is a risky change !Lets zoom in on the reasons to change software for a moment
  • Adding a feature or fixing a bug: Behavior is the most important thing about software. It is what usres depend on. Users like it when we add new behavior (provided it is what the really wanted), but if we change or remove behavior they depend on (introduce bugs), they stop trusting us.Refactoring: Make changes without changing he behavior. Make software more maintainable. It is a risky change !Lets zoom in on the reasons to change software for a moment
  • I can just do it inside the current method ... Then I can see the new code and the old code together. Its saferHave you ever had the feeling like juming of a cliff when making code changes? Assessing problems.Is unreadable working code that much better then readable working code? Then how will the code stay readable, understandalbe, ...?Fear of introducing bugs, working to long a a specific problem... One solution: educate yourself, learn new, better techniques and the fear will fade away.
  • It is, IMHO, also our standard. It can also be read as working with care.We spend extra care when the changes are invasive, but is that the same thing as safety? Effective software change is like an effective surgeon right... Would you let a surgeon cut you open with a butter knife if he is working with care? So if we wouldn’t do that we could infere that the right tools and the right technique is more important than working with care.
  • Higher level testing is something that should be supported by your unit tests.Test covering is something that helps you see how much of the code is tested.
  • Whoknowswhat unit testing is ??? Informatica.bedudes ??? Ever doneone in a work environment?Ok and now?When we have unit tests in place, like we should have, we can make changes and be sure that we haven’t broken anything else.But now we have a small problem.Next: Legacy code dilemma
  • So you can see the dilemma.So what we will try to do is the following mantra
  • Nextslide > sensing and seperation. (dependencybreaking)
  • There are 2 reasons to break dependencies: One of the big problems in legacy code is dependency. Objects that rely on other objects that rely on other objects and so forth.
  • What kind of framework supports this?
  • A seam is a place where you can alter behavior in your program without editing in that place.You can do link seams > ie with a dependency injection framework, but make sure that you use clear naming so you don’t mess up when deploying to production
  • Unit testing, mocking, refactoring
  • Sprout class and method are good when you need to add a new feature and the new feature is new code entirely.Use it to seperate the old and new code.The disadvantage of this is that you didn’t place the code in a test harness.Wrapping a method or a class is much like the decorator pattern. You leave the old code but wrap it with new code / features.Both cases aren’t ideal because the code is still untested... The only advantage between this and just writing your changes in the method or class you need to add the feature for is that the code is cleanly seperated.
  • 1. Understanding a well-maintained system takes time. You need to figure out what to change and where. Once you know what to change its usualy easy and you feel you got more comfortable with the system. In a legacy system this is not the case. The code is entangled and difficult to understand. Systems that are broken up in smaller pieces are easier to understand. So that is our goal.2. Build, deploy to staging or wait for cassini to start, check the change you made... This takes a lot of time to know if your code changes are the correct changes.3. in order to get testable pieces of code this is something we need to do.
  • Next slide = TDD for legacy
  • Programming by difference: Override a class to make a different implementation. Make sure you don’t violate the Liskov substitution principle. So objects of subclasses should be able to replace the superclass objects. If you don’t do this we could have silent errors.
  • Make sketches while reading through the code.Listing markup > sort methods > seeresponsabilitiesDelete unused code > example > recytyreMemberAddressAdapter

Working Effectively with Legacy Code Working Effectively with Legacy Code Presentation Transcript

  • 29 January 2010
    Working Effectively with Legacy Code(book review)
  • 29 January 2010
    Working Effectively with Legacy Code (book review)
    2
    Bookreview
    WorkingEffectivelywithLegacy Code
    By Michael C. Feathers
    http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052
    Agenda
    The mechanics of change
    Changing software
    Dependencybreakingtechniques
    Thissession is fordeveloperswhoneed to workon code projectsthatwherewritten without goodunit-testing.
  • Part 1: The mechanics of change
    Workingeffectivelywithlegacy code
    29 January 2010
    3
    Working Effectively with Legacy Code (book review)
  • 4
    Working Effectively with Legacy Code (book review)
    29 January 2010
    Four reasons to change software:
    Adding a feature
    Fixing a bug
    Refactoring
    Optimizing resource usage
    Changing Software
  • Four reasons to change software
    29 January 2010
    5
    Working Effectively with Legacy Code (book review)
  • Changing Software
    Four reasons to change software:
    Adding a feature
    Fixing a bug
    Refactoring
    Optimizing resource usage
    Risky change
    What changes do we have to make?
    How will we know that we’ve done them correctly?
    How will we know that we haven’t broken anything?
    29 January 2010
    6
    Working Effectively with Legacy Code (book review)
  • What? Create another method for that? ...
    Am I ready to do it? I guess I have to ...
    If it’s not broke, don’t fix it !!!
    Fear
    Risky change
    29 January 2010
    7
    Working Effectively with Legacy Code (book review)
  • Edit and pray
    (Industry standard)
    Cover and modify
    Working with Feedback
    Working Effectively with Legacy Code (book review)
    29 January 2010
    8
  • Edit and pray (Industrystandard)
    Carefully plan the changes
    Make sure you understand the code
    Start making changes
    Poke around to see if you broke anything
    Deploy to production environment
    Wait for feedback from customers or elmah
    29 January 2010
    9
    Working Effectively with Legacy Code (book review)
  • Cover and modify
    Safety net
    Covering = testing
    What is Unit Testing?
    Higher level testing
    Test coverings
    The legacy code change algorithm
    29 January 2010
    10
    Working Effectively with Legacy Code (book review)
  • What is Unit testing?
    Properties:
    isFast = true;
    canLocaliseProblems = true;
    canTalkToDatabase = false;
    canCommunicateWithNetwork = false;
    canCommunicateWithLocalResources = false;
    needsConfigChanges = false;
    29 January 2010
    11
    Working Effectively with Legacy Code (book review)
  • When we change code, we should have tests in place.
    To put tests in place we need to change code
    The legacy code dilemma
    29 January 2010
    12
    Working Effectively with Legacy Code (book review)
  • The legacy code change algorithm
    • Identify change points
    • Find test points
    • Break dependencies
    • Write tests
    • Make changes and refactor
    29 January 2010
    13
    Working Effectively with Legacy Code (book review)
  • Sensing: we break dependencies to sensewhen we can’taccessvaluesour code computes.
    Seperation: we break dependencies to seperatewhen we can’t even get a piece of code into a test harness to run.
    Sensing and Seperation
    29 January 2010
    14
    Working Effectively with Legacy Code (book review)
  • Create a dummy or fake class
    Add some methodssoyou can access the values to check
    Repeat until all dependencies are tested
    OR use a framework that allows us to do this
    Faking collaborators
    29 January 2010
    15
    Working Effectively with Legacy Code (book review)
  • The Seam Model
    29 January 2010
    16
    Working Effectively with Legacy Code (book review)
  • Tools
    29 January 2010
    17
    Working Effectively with Legacy Code (book review)
  • Part 2: Changing Software
    Working effectivelywith legacy code
    29 January 2010
    18
    Working Effectively with Legacy Code (book review)
  • Quick overview (what is yet to come)
    I don’t have much time and I have to change it
    It takes forever to make a change
    How do I add a feature
    I can’t get this class into a test harness
    I can’t run this method in a test harness
    I need to make a change. What methods should I test?
    I need to make many changes in one area
    I need to make a change, but I don’t know what tests to write
    Dependencies on libraries are killing me
    My application is all API calls
    I don’t understand the code well enough to change it
    This class is too big and I don’t want it to get any bigger.
    I’m changing the same code all over the place
    I need to change a monster method and I can’t write tests for it.
    How do I know I’m not breaking anything?
    We feel overwhelmed. It isn’t going to get any better.
    29 January 2010
    19
    Working Effectively with Legacy Code (book review)
  • I don’t have much time and I have to change it
    • Sprout method
    • Sprout class
    • Wrap method
    • Wrap class
    29 January 2010
    20
    Working Effectively with Legacy Code (book review)
  • It takes forever to make a change
    • Understanding
    • Lag time
    • Breaking dependencies
    29 January 2010
    21
    Working Effectively with Legacy Code (book review)
  • How do I add a feature
    Test-Driven Development (TDD)
    1. Write a failing test
    2. Get it to compile
    3. Make it pass
    4. Remove duplication
    5. Repeat
    Programming by difference
    29 January 2010
    22
    Working Effectively with Legacy Code (book review)
  • How do I add a feature
    Test-Driven Development (TDD) for legacy
    0. Get the class you want to change under test
    1. Write a failing test
    2. Get it to compile
    3. Make it pass (try not to change existing code)
    4. Remove duplication
    5. Repeat
    Programming by difference
    29 January 2010
    23
    Working Effectively with Legacy Code (book review)
  • I can’t get this class into a test harness
    The case of the ...
    • Irritating parameter
    • Hidden dependency
    • Construction blob
    • Irritating global dependencies
    • Onion parameter
    29 January 2010
    24
    Working Effectively with Legacy Code (book review)
  • I can’t run this method in a test harness
    The case of the ...
    • Hidden method
    • Undetectable side effect
    29 January 2010
    25
    Working Effectively with Legacy Code (book review)
  • Reasoning about effects
    Reasoning forward
    Effect propagation
    Tools for effect reasoning
    I need to make a change. What methods should I test?
    29 January 2010
    26
    Working Effectively with Legacy Code (book review)
  • Interception points
    Judging design with pinch points
    Pinch point traps
    I need to make many changes in one area
    29 January 2010
    27
    Working Effectively with Legacy Code (book review)
  • Characterization tests
    Characterizing classes
    Targeted testing
    I need to make a change, but I don’t know what tests to write
    29 January 2010
    28
    Working Effectively with Legacy Code (book review)
  • Dependencies on libraries are killing me
    29 January 2010
    29
    Working Effectively with Legacy Code (book review)
  • I don’t understand the code well enough to change it
    • Notes/Sketching
    • Listing markup
    • Scratch refactoring
    • Delete unused code
    29 January 2010
    30
    Working Effectively with Legacy Code (book review)
  • This class is too big and I don’t want it to get any bigger.
    • Seeing responsibilities
    • Other techniques
    29 January 2010
    31
    Working Effectively with Legacy Code (book review)
  • I’m changing the same code all over the place
    29 January 2010
    32
    Working Effectively with Legacy Code (book review)
  • Varieties of monsters
    Tackling monsters with automated refactoring support
    Strategy
    I need to change a monster method and I can’t write tests for it.
    29 January 2010
    33
    Working Effectively with Legacy Code (book review)
  • How do I know I’m not breaking anything?
    • Hyperaware editing
    • Single-goal editing
    • Preserve signatures
    • Lean on the compiler
    29 January 2010
    34
    Working Effectively with Legacy Code (book review)
  • Create oases
    We feel overwhelmed. It isn’t going to get any better.
    29 January 2010
    35
    Working Effectively with Legacy Code (book review)
  • 36
    Working Effectively with Legacy Code (book review)
    29 January 2010