|
|
|
|
|
Activity:
Refactor Code
|
|
Participating Roles
Responsible:
Developer |
To refactor code, complete one change at a time and perform unit tests afterward. This approach minimizes potential code breakage. Use automated refactoring whenever possible as the automated processes are less likely to cause functionality to break. Refactoring is a continuous activity that keeps the code base open to change.
Entry Criteria
Dependencies:
- Unit tests for the area are up-to-date and run successfully.
Sub-Activities
|
1 |
Identify Complexity |
- When functionality is added, look for areas of code that increase architectural complexity.
- Identify the appropriate refactoring to reduce the complexity while keeping the semantics of the code the same.
- Identify and run the unit tests for the area to be refactored.
|
2 |
Apply Refactoring |
- Apply the refactoring, one at a time. Change the code and all the references to the changed area as necessary.
- If a class does not map to an abstraction of a real world or programmatic element, rename the class to a name that maps appropriately. Change all of the references to the code.
- If methods are too complex, it may be necessary to break a method up into a set of new methods. Use "extract method" to pull out functionality that belongs in its own method. Be sure the new method is consistent with the abstraction (class name) in which it is added.
|
3 |
Perform Unit Tests |
- Perform unit tests so the area remains semantically equivalent after the refactoring. Fix any nonworking unit tests.
- Perform code analysis and fix any warnings.
- Perform unit tests again if code changes are made as a result of code analysis.
|
Exit Criteria
|
The code or architectural complexity is removed and unit tests run successfully. | |
|
|
|
|
© 2005, 2006 Microsoft Corporation. All rights reserved.
Version 4.0.1 |
|