Change Management Dr. James A. Bednar jbednar@inf.ed.ac.uk - - PowerPoint PPT Presentation

Change Management

• Dr. James A. Bednar

jbednar@inf.ed.ac.uk http://homepages.inf.ed.ac.uk/jbednar

SAPM Spring 2007: Change 1

Change is Inevitable

Even brand-new systems will often or typically need to:

• Interface with existing components that cannot be

replaced (usually undocumented, sometimes without source code)

• Reproduce functionality of old, badly designed

systems in current use, without breaking anything

• Go through many revisions during development

In this lecture we discuss how to handle changes to code, whether pre-existing (legacy systems) or newly developed.

SAPM Spring 2007: Change 2

1st Step: Revision Control

Before starting any project (programming or otherwise!) with edits occuring over more than a couple of weeks, you should set up a revision control system. If you do not, you deserve every one of the many troubles that will be coming your way. Revision control systems are also called configuration management systems, but what they really do is track changes during development and maintenance. We will primarily discuss CVS in this course, but the Tools lecture will mention alternatives, such as Subversion.

SAPM Spring 2007: Change 3

Revision Control System Features

• Have master repository holding all versions of all files
• Changes in local copies don’t affect the repository

until a commit (a.k.a. checkin)

• Commits merge your changes and those of other

users with the repository files

• Locking mechanisms prevent collisions
• Can provide complete history of all changes,

reproducing state at any time and tracking who changed what when

SAPM Spring 2007: Change 4

CVS Example

UNIX> cvs update UNIX> cvs diff -r 1.1 tools.tex 29c29 < is teh best

• >

is the best UNIX> cvs commit -m "Fixed typo" tools.tex UNIX>

Here I had edited the file tools.tex, so I updated my copies to make sure they were current, checked the diffs, then committed my change. The new version of tools.tex is now 1.2, with the current date stamp.

SAPM Spring 2007: Change 5

Managing software releases

• Any decent company will have revision control
• Release to the public: modified snapshot of repository
• Typical sequence for a release:
• 1. Feature freeze (only bugfixes allowed now)
• 2. Release candidate (could ship if bug-free)
• 3. Candidate sent to testing team
• 4. Bugs are found, patched ❀ new release candidate
• Often different code branches are maintained

(production and development)

SAPM Spring 2007: Change 6

CVS in SAPM

We will use CVS to coordinate work between members of each team. It is not optional. If you have trouble getting it to work, we need to sort that out. There is no way to do well on either assignment without the whole team using CVS. CVS will allow each team member to submit work for the rest of the team to read, comment on, and edit. Note: If most of your team already knows CVS, then consider using Subversion instead for the experience, though I cannot provide docs and examples for Subversion.

SAPM Spring 2007: Change 7

Refactoring

Assume that a revision control system is in place, and that we have either a partially implemented system or a legacy system to which we would like to add a feature. Ideal: Just find where the new feature would go, and write the appropriate code. Actual: Extensive changes are often needed to the existing code before the new feature can be added. Refactoring: improving the existing design without adding functionality (Fowler et al. 1999)

SAPM Spring 2007: Change 8

Refactoring Approach

Whenever the current design makes it unwieldy to implement a desired function or feature:

• 1. Step back and re-design the existing code so that it

will make the feature easy to add

• 2. Make sure that the code meets the same tests as

before, i.e., provides the same functionality.

• 3. Integrate the changes with the rest of your team.
• 4. Make the change, pass the tests, and integrate again.

SAPM Spring 2007: Change 9

Testing and Refactoring

• Refactoring works well in combination with regression

tests (see the Verification and Validation lecture).

• Before refactoring, set up a good test suite that can be

run quickly and will automatically verify all results.

• The tests can verify that a refactoring does not

change the program behavior.

• Typically: run tests as-is before and after refactoring,

then modify the code and the tests, and again verify the tests run ok.

SAPM Spring 2007: Change 10

Revision Control and Refactoring

Adding a feature using CVS, testing, and refactoring:

• 1. cvs commit .

(Commit all outstanding edits)

• 2. emacs

(Refactor, not changing behavior at all)

• 3. make tests

(Regression test)

• 4. cvs diff

(Will have many changes)

• 5. cvs commit -m "No visible changes" .
• 6. emacs

(Add new feature)

• 7. make tests

(Regression test)

• 8. cvs diff

(Short list: only the new code)

• 9. cvs commit -m "Added feature Y" .

Goal: validate nearly all changes against existing tests, then debug new user-visible change/feature by itself.

SAPM Spring 2007: Change 11

Refactoring Legacy Code

Assume that we have want to add features to a legacy system that has a complicated, suboptimal design. Refactoring+testing approach:

• 1. Set up tests to capture current behavior (time-consuming)
• 2. Gradually refactor as code is understood (also slow)
• 3. Once the design is relatively clean and appropriate for

the types of changes now expected, start adding features (now easy) Benefit: it’s usually obvious what to do next

SAPM Spring 2007: Change 12

Adapter Pattern

Often, it’s better just to draw a fence around legacy code, and not attempt to improve it. E.g. if there is an obscure, undocumented component that is known to be extremely reliable, refactoring would be difficult. Instead, wrap up the old FORTRAN or COBOL component as a nice-looking object in the new development language, use the adapter in the future, and never touch the old code again. Benefit: Keeps old bad code from tainting new good code.

SAPM Spring 2007: Change 13

Keeping the System Running

New projects are often designed to replace an existing body of lousy code in current use, but adding features. Many such projects fail by being overly ambitious. Often, the developers go far out on a limb adding fun new features and improvements, before the system has been put into real use. The longer this goes on, the lower the likelihood of the new system ever being used. The alternative of making small changes that keep the old system working continuously is very hard, but it’s a good way to minimize the chance of total failure.

SAPM Spring 2007: Change 14

Summary

• Change is inevitable — prepare for it.
• Put a revision control system in place. Now.
• Refactoring helps keep you (and your design!) sane

when making changes.

• Refactoring, testing, and revision control help much

when changing legacy code. Required reading: Fowler et al. 1999, Chapter 2, plus list

• f soundbites at the end of the book.

SAPM Spring 2007: Change 15

References

Demeyer, S., Ducasse, S., & Nierstrasz, O. (2003). Object-Oriented Reengineering Patterns. San Francisco: Morgan Kauffman. Fowler, M., Beck, K., Brant, J., Opdyke, W., & Roberts, D. (1999). Refac- toring: Improving the Design of Existing Code. Reading, MA: Ad- dison Wesley.

SAPM Spring 2007: Change 15