I'm working on an application (hobby project, solo programmer, small-medium size), and I have recently redesigned a significant part of it. The program already works in it's current state, but I decided to reimplement things to improve the OO design.

I'm about to implement this new design by refactoring a big part of the application. Thing is I'm not sure where to start. Obviously, by the nature of a rearrangement, the moment you change one part of the program several other parts (at least temporarily) break. So it's a little 'scary' to rearrange something in a piece of software that already works.

I'm asking for advice or some general guidelines: how should I approach a significant refactoring? When you approach rearranging large parts of your application, where do you start?

Note that I'm interested only in re-arranging the high-level structure of the app. I have no intention of rewriting local algorithms.

  • recommended reading: Where to start? – gnat Aug 21 '14 at 21:28
  • 1
    possible duplicate of I've inherited 200K lines of spaghetti code -- what now? – user53019 Aug 21 '14 at 21:32
  • google 'joel spolsky rewrite' - his article is good, as are many of the replies. tl;dr version - why rewrite working code? – Dan Pichelman Aug 21 '14 at 21:40
  • "Obviously, by the nature of a rewrite, the moment you change one part of the program several other parts (at least temporarily) break.": This depends on how tightly coupled different parts are. A good starting point could be trying to reduce coupling. – Giorgio Aug 21 '14 at 21:46
  • 1
    Things You Should Never Do, Part I – user22815 Aug 21 '14 at 21:54

Rewriting a complete application just because you don't like the code is usually not a good idea. Refactoring just for the sake of refactoring usually doesn't fix any problems, but introduces several new ones.

When you've learned something new which would totally improve the design of your previous application, resist the urge to rewrite it. There will always be a next project where you can apply your knowledge.

The only situation where large-scale refactoring makes sense is when you try to add a new feature, and you realize that the current architecture doesn't allow to do it in an elegant way. Then you might consider to do the necessary rewrites while developing that feature. Just don't forget about your goal: Getting that feature to work.

  • I see what you mean and actually I'm glad to hear it. Indeed I "learned something new" (received feedback for my design on this site) and decided to improve my app according to the criticism, but immediately regretted it when I realized it will be a big deal. So I'll save my new found knowledge for the next project :) – Aviv Cohn Aug 21 '14 at 22:40
  • If it ain't broke, don't fix it. – user22815 Aug 21 '14 at 23:13

Spend most of your time up front writing comprehensive and detailed unit and integration tests. They are the piece that will tell you if changes are breaking other pieces.

Then change pieces in a small a step as possible and run all the above tests, plus manual testing, between each step.

For the changes being made, use a distributed version control system like git so you can apply and rollback changes.

  • 3
    Could not agree with this more strongly. Quality tests are the #1 thing you can do to make changing code effective. #2 is probably having a good source repository (e.g. Mercurial or git). – Jonathan Eunice Aug 21 '14 at 22:51
  • Since he is leaving "smaller" code alone, unit tests are absolutely required to ensure the larger architectural changes do not break the little things. This is pretty much the same approach that Uncle Bob recommends. – user22815 Aug 21 '14 at 23:13
  • Yeah dvcs is needed. Added. – Michael Durrant Aug 22 '14 at 10:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.