Tuesday, April 24, 2007

6 Tips for Refactoring

Here are some top 6 tips that I have identified during the course of my research on refactoring.

Identify the code that smells badly using appropriate static analysis tools effectively.

Most of the static analysis tools (freeware/commercial) come with pre-defined business rules to identify most of the re-factoring candidates. These business rules can also be customized based on the organizational standards and also new business rules can be created.

Typical business rules include checking and correcting of:
  • Naming Conventions
  • Coding styles
  • Cut and Paste problems
  • Duplicate code
  • Redundant checks
  • Empty blocks
  • Too many logical conditions in a single expression
  • Unused code
  • Coupling
  • Package dependency
List of static analysis tools are available in:
http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis
http://www.refactoring.com/tools.html

Pick out the poor documentation practices using automatic document generation tools.

Most of the document generation tools can generate the necessary documentation using the comments provided in the code. So, poorly commented code results poor documentation. Also usage of automatic document generation tools imposes unique style of writing comments.

Use automatic test case design tools to continuously test your refactoring changes
JTest and C++ Test from parasoft are exmaples for the same. Most of these tools sniff into the software components for methods and generate the test cases for the same.

Label your re-factoring changes separately
With labeling we can isolate the changes from functional changes. The cause of refactoring is preserved and can be undone in case of refactoring results in poor software

Prepare a dependency matrix for your code with design and architectural artifacts.
This helps in
updating the artifacts when ever code is refactored and validate the code against the architecture and design.

Create a complexity trackers for each software component based on coupling, number of bugs in the past.
If a component has tight coupling and had more number of bugs then the component considered to be highly complex. If a component is higly complex then more emphasis can be put on testing the code that is refactored.

In my opinion "continuous and goal oriented refactoring satisfies the needs of a strategic evolution of products"


No comments: