#refactoring
3 posts

Avoid rewriting a legacy system from scratch, by strangling it

There comes a point when there is so much technical debt in your legacy project that you can no longer implement new features. Yet rewriting from scratch is risky and refactoring is expensive.
Read more

Avoid rewriting a legacy system from scratch, by strangling it

  • There comes a point when there is so much technical debt in your legacy project that you can no longer implement new features. Yet rewriting from scratch is risky and refactoring is expensive.
  • ‘Strangle’ the codebase instead, progressively deleting the old codebase in favor of building a new one. It has less risk of breaking things and is less work overall.
  • To strangle the codebase:
  1. Write new code that acts as a proxy for the old code: users come to the new system, which actually redirects to the old one behind the scenes.
  2. Build new modules to re-implement each of the legacy behaviors in the new codebase, such that there is no change from the user perspective.
  3. Progressively fade away the old code from use until users are entirely consuming the new modules.
  4. Delete the old, unused code.
  • Use techniques such as wrap classes to add new behaviours to the system without changing existing code at first, which also separates new and old responsibilities while integrating them. Or you can use the domain-driven design (DDD), with the legacy system as a black box and building a bubble context where you apply DDD, interacting with the black box through an anti-corruption layer. Roll out the rewrites progressively.

Full post here, 5 mins read

How to refactor a monolithic codebase over time

If source code is not stored under version control, get it under version control. Check for static code analysis. If there is no test suite, build that before you refactor. If
Read more

How to refactor a monolithic codebase over time

  • Understand the application thoroughly. Talk to previous developers, business owners, PMs, etc. Read through code comments, code commit messages, README files, documentation, wikis. Checking the bug-reporting tool used as well. Put all the learning together.
  • If source code is not stored under version control, get it under version control. Check for static code analysis.
  • If there is no test suite, build that before you refactor. If there is a test suite, understand the level of code coverage. Check how long it takes to complete the suite, whether it exhausts available memory, how many tests fail, are skipped or are outdated, whether there is a good mix of unit, integration and functional tests, whether there are sections of codebase escaping coverage. Also, look for comments indicating something that was to be fixed later.
  • Begin refactoring, keeping in mind that your code will never be perfect. So know when to move on.
  • To clean up a complex codebase, sometimes you need to make seemingly trivial changes. But most of the changes should have a clear, effective purpose, such as creating a new feature or fixing a bug or defect.
  • Work to a project plan, with a series of achievable tasks, a realistic timeline, and resource requirement, sufficient staff to work on the tasks in isolation or in parallel with other projects.

Full post here, 8 mins read

Lessons learned from the Ruby Refactoring Kata - Tennis Game

Refactoring mercilessly is a great learning technique to learn about what different parts of the code do. Don’t trust the initial tests completely. There are great chances they may not give you complete coverage.
Read more

Lessons learned from the Ruby Refactoring Kata - Tennis Game

“There is a certain amount of Zen to refactoring. It is hard at first because you must be able to let go of that perfect design you have envisioned and accept the design that was serendipitously discovered for you by refactoring. You must realize that the design you envisioned was a good guidepost, but is now obsolete.”
  • Refactoring mercilessly is a great learning technique to learn about what different parts of the code do.
  • Don’t trust the initial tests completely. There are great chances they may not give you complete coverage.
  • Extract method is a no-brainer refactoring with a good IDE support.
  • Simplify if conditions with Guards.
  • Preserve the public API if you have no control over client calls.
  • “Code as data” sounds exciting in theory. It isn’t too great in practice.

Full post here, 12 mins read