, , , ,


Recently overheard heated debate on code refactoring. I felt they were mixing up refactoring with rework and agile model was being blamed for not designing upfront therefore need for code refactoring. This resulted in waste of time, organically grown-poorly-commented-complex- code that needed retesting.

So, why and when do I refactor my code?

Simple answer is, when you are sure that you will never ever have to touch a piece of code again, there’s no need to re-factor that code.

But most of the time, you will have to touch it again because you will have to add features, fix bugs or optimize it.

  1. To eliminate/reduce the “Code Smells”
  2. Easier for any developer to understand the code
  3. To make it maintainable.
  4. To increase cohesion and to reduce coupling”

I don’t usually recommend refactoring just to reduce code smells, or make it ‘nicer’/more maintainable. I do suggest you refactor your code, when you need to fix bug, and you want to leave code in better shape than it was before. Other reason is when you want to add functionality, and it would be hard to do without refactoring. Third reason is to make code more testable. Sometimes refactoring will help you to learn the code which you don’t understand 🙂

Refactoring is used to pay your Technical Debt. Code refactoring is a necessity of observing the fact that change is inevitable. It’s principal goal is to enhance the current code or design in order to make it amenable and congruent with new functional or non-functional requirements or to make it more tolerant to change.

Examples of scenarios where refactoring may be necessary:

• Introduction of a new business rule that requires the current design to be abstracted to a new level;
• Recognition of the fact that the current design could be modified in order to better observe the SOLID principals of object-oriented design;
• When code testability needs to be increased—this relates to 2 above.

While you are refactoring
• Avoid code duplication when I see it (following DRY principle-need to write a blog on this too)
• Simplify the code (remove unnecessary ad-hoc complexities, KISS- keep it simple and stupid)
• Remove old/stale/deprecated code (cleaning waste, once the old code is replaced)
• Eliminate side effects
• Generalize and reuse existing code
• Reducing complexity of individual functions – makes testing easier
• Eliminating repeated code – reduces opportunities for mistakes

And finally, Its not waste of anybody’s time!!!!

1 reply
  1. Gabrielly
    Gabrielly says:

    I agree with you that the name “getFriendTrips” for the method is still not good engouh. Probably your suggestion is a better one. As this is supposed to be a “legacy” system (exercise), changes need to be done bit by bit. When working with legacy, we need to be careful with assumptions and also try not to be carried away and try to refactor the whole code base in one go. Very good points guys. Thanks.


Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *

2 + 9 =