ICS 121: Maintenance: Modularity and Refactoring

Maintenance is all the work that needs to be done on a software product after it is initially put into use.
In older views of software development, maintenance was seen as one additional step after implementation, test, and deployment. Unfortunately, this one step gradually took a bigger and bigger percentage of effort.
Now, maintenance is seen as a new iteration of the development life-cycle where work starts with revising the requirements of the previous release rather than starting from a blank page.
If a product has 20 releases in 6 years, 19 of those release involve maintenance.
Common types of changes in post-1.0.0 releases:
- Defect repair
- Keeping up with environmental change (e.g., Windows XP comes out)
- Enhancements to existing features
- Whole new features
- Design and implementation improvements
- Performance enhancements
Maintenance effort is determined by:
- Design understandability and modularity
- Coding style understandability
- Implementation quality: number of existing defects
- Understandability of technical documentation
- Skills and experience of development team
- Scope of requested changes
- Tools available for maintenance
Note: The term "maintenance release" is more narrowly defined: it refers to a 3-digit release, e.g., 2.0.1. These releases typically have only defect repair, not new functionality.

Modularity is how well the product is divided into independent modules
Low coupling
High cohesion
Things to look for:
- Cycles in the package dependency graph
- Classes with too many import statements
- Public attributes
- One class treats another class like a simple data record

Refactoring is moving pieces of source code from one place in the system to another, changing a method signature, or changing the class structure, or renaming elements.
Refactoring is typically tedious and error prone because a developer must search through all the other code and make corresponding changes.
Refactoring can be made easier with tools
- A good search and replace utility always helps, but cannot catch everything
- Round-trip UML tools read code, allow design changes, then generate revised code
- Newer IDEs and editors have sophisticated commands for specific refactoring operations
Guidelines for refactoring:
- Have a specific goal in mind, don't just polish code endlessly. Don't do it everyday when you feel like it, do it according to a project plan.
- Do not refactor and add new logic at the same time: finish one and test, then do the other
- Run automated regression tests before and after a refactoring session. You should get the same results.
- Manage the scope of the change. Refactor in short, deliberate steps and test after each step.
- Keep in mind that other code that you cannot edit might depend on your API. In java, mark old methods with deprecated javadoc tag.
For more, see Eclipse documentation on refactoring