It seems nearly impossible to add behavior without changing it to some degree.Improving design – a series of small structural modifications, supported by tests to make the code easier to change.Optimization – functionality exactly the same but changing something else (usually time or memory)
Talk about a team policy where – if it’s not broke, don’t fix it. – Talk about problems it createsDifference between good and bad systems
Working with care – leads to using tools and techniques inefficiently
Use of safety netCovering software means covering with testsTesting to attempt to show correctnessVsTesting to detect change – tests as software vise – keep most of the behavior fixed and change only what you intend toRegression tests with or without writing tests – mention a story about doing the testing at the end
Other kinds of tests often masquerade as unit tests. A test is not a unit test if:It talks to a database.It communicates across a network.It touches the file system.You have to do special things to your environment (such as editing configuration files) to run it.
Servlet and DBConnection are two issuesPossible option – pass real db connection but how about servlet itself
Mock objects are advanced type of fakes.
A seam is a place where you can alter behavior in your program without editing in that place.
We need to add code to verify that none of the new entries are already in transactionBundle before we post their dates and add them.
Disadvantages: Giving up on the codeAdvantages: Separating new code from old code
Every time that we pay an employee, we have to update a file with the employee's name so that it can be sent off to some reporting softwareThe easiest way to do….is method
We create a method with the name of the original method and have it delegate to our old code
Use of decoratorToolController controller = new StepNotifyingController( new AlarmingController ( new ACMEController()), notifyees);
Without using decorator
Working effectively with legacy code
Working Effectively with Legacy Code – Part I<br />-ShriKantVashishtha<br />Aug 19, 2009<br />
Four Reasons to Change Software<br />Adding a feature<br />Fixing a bug<br />Improving the design<br />Optimizing resource usage<br />
A Legacy Code Scenario<br />What changes do we have to make?<br />How will we know that we have done them correctly<br />How will we know that we haven’t broken anything<br />Avoiding change is a bad thing, but what is our alternative?<br />Try harder. Hire more people<br />
Legacy Code Dilemma<br />When we change code, we should have tests in place. To put tests in place, we often have to change code.<br />Use Primitivize Parameter and Extract Interface to remove these issues<br />
Wrap Method<br />Advantages<br />A good way of getting new, tested functionality into an application when we can't easily write tests for the calling code<br />It explicitly makes the new functionality independent of existing functionality<br />Disadvantages<br />Can lead to poor names<br />
Wrap Class<br />Able to add new behavior into a system without adding it to an existing class<br />When there are many calls to the code you want to wrap, it often pays to move toward a decorator-ish wrapper<br />If new behavior has to happen at couple of places, simple class wrapper is very useful<br />
I Don't Have Much Time and I Have to Change It: Summary<br />Use Sprout Method when the code you have in the existing method communicates a clear algorithm to the reader. <br />Use Wrap Method when you think that the new feature you’re adding is as important as the work that was there before<br />Use Wrap Class when the behavior that I want to add is completely independent<br />