Refactoring

Redoing things is fundamental to every creative process

In Agile, working software is the primary measure of success but how to ensure that developed software code is not buggy and is of high quality, and that the cost of maintenance later are reasonable.

Not all Working Codes are Good Codes.

As in Agile method of software development, pace of development is fast, team should ensure that they are giving due importance to one of the very important agile principle which says, “Continuous attention to technical excellence“.

Refactoring is like continuing repair of a living system. The goal is to stay within reasonable operating limits with limited continual damage. By staying within these limits you keep costs low, because costs relate nonlinearly to the amount of repair necessary. It is like maintaining your house. You are best off (financially) if you continuously maintain rather than do large lump repairs.

Dirk Riehle

Although refactoring improves the overall code quality but some time Product Owner/Management don’t fund the Refactoring cost, either due to financial constraints or to meet some challenging delivery schedule. Teams, sometime take short-cuts due to delivery pressure and end-up adding duplicates codes that does not follow the set standard like proper naming conventions or teams does not fully analyze the ill effect of utilizing wrong constructs or logic. To alleviate these deficiencies in working code refactoring of the codebase is important and required.

Refactoring secures short-term as well as long-term gains to keep tab on maintenance cost and to improve codes maintainability, readability, scalability and portability.

So, why to do Refactoring? What are the benefits of Refactoring?

• It Prevent “design decay”
• Clean up messes in the code
• Simplify the code
• Increase readability and understandability
• Find bugs
• Reduce debugging time
• Build in learning we do about the application

What should be our purpose of doing Refactoring?

• To Make the code simpler and easier to understand
• Make code more flexible
• Make code easier to change
• Remove duplication or needless complexity
• Enhance Software Quality, and
• Do not change observable behavior (all tests should still pass)

Things to remember..

When refactoring Legacy Code, first write Tests to lock in current behavior, then Refactor.

Refactor only when suitable Test Coverage has been achieved.

Then, there are certain criteria’s that should be met, before undertaking Refactoring exercise, like..

• Collective code ownership
• Coding standards should be in place
• Simple design
• Test automation
• Continuous Integration should be in place
• Rested Programmers-programmers should have enough time to study, think and rethink
• Many times Pair programming also helps

Where to refactor?

• Tests exist and currently pass for the code to be refactored
• Someone else is not concurrently working in the same code
• The customer agrees that the area is worth the time and money to refactor

When to refactor?

• “All the time”

• Rule of Three

1. When you add functionality
2. When you learn something about the code
3. When you fix a bug

… and When the code smells

When NOT to refactor?

• When the tests aren’t passing
• When you should just rewrite the code
• When you have impending deadlines

Is there any problem doing refactoring?

• Taken too far, refactoring can lead to incessant tinkering with the code. Trying to make it perfect.
• Refactoring code when the tests don’t work or tests when the application doesn’t work leads to potentially dangerous situations.
• Databases can be difficult to refactor
• Refactoring published interfaces can cause problems for the code that uses those interfaces

Refactoring in reference to Test-driven Development (TDD):

Why developers are reluctant to refactor?

• Short-term focus
• Lack of understanding
• Fear of breaking current program
• Not paid for overhead tasks like refactoring

How pair-programming (PP) could impact refactoring activities?

Pair-Programming can greatly improve the quality of code as well as could result in considerable saving in the bug-fix efforts. Please have a look at my blog on “Pair-Programming“.

@Mohammad Sami _{-Agile Transformation Coach}

Also check my blog on Continuous Delivery (CD): Continuous Delivery (CD) is the process that moves codes from Test environment to Acceptance environment to Prod environment, taking out dependency from human being and reassign dependency on process with high degree of automation where releasing software becomes routine. Please see my blog on Continuous Delivery.

Also check my blog on Continuous Integration (CI): In software engineering, Continuous Integration is the practice of merging and building (and automation testing) all developer working copies to a shared mainline several times a day or sometimes on every code check-in (if infrastructure supports that). CI keeps the entire development team in sync, removing the delays due to integration issues. Please see my blog on “Continuous Integration”.

NOTE: Please note that due to some technical issues we have lost users comments until February 2022. My apologies. Please do comment and share your thoughts in the comments below