#Issue123
2 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

Reasons why you should be coding with interfaces

Interfaces enable you to code against pure abstractions, not implementations. Pure abstraction is the best thing for loose code coupling.
Read more

Reasons why you should be coding with interfaces

  • Interfaces enable you to code against pure abstractions, not implementations. Pure abstraction is the best thing for loose code coupling.
  • Interfaces let you make the coupling between classes also very loose, which lets you alter your implementations at runtime more easily, in turn allowing you to create very pluggable implementations for when you think of a better way to do something without having to change your code radically.
  • Interfaces allow for good inter-module communications, especially useful when you have different teams working on different modules - this way, you don’t need to know how the other team’s code works to interface with it.
  • Interfaces make your code more testable because you can readily substitute implementations, even a fake one. This lets you test using, for example, a fake database returning canned data instead of actually having to connect to and use an active, vulnerable database.
  • Interfaces are useful for implementing design patterns such as Model-View-Controller (MVC) and Model-View-ViewModel, and for dependency injection frameworks.

Full post here, 6 mins read