#refactoring
2 posts

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