Refactoring toward a longer-term goal

I was working in a project that had its own custom roles and permission system. Over the years, this system had evolved into something that was getting hard to maintain.

Now, a new feature was requested with a new set of permissions that would not would work with this legacy system. And on top of that, the project was already planning a future move to a more robust open source roles and permissions package, but they weren't ready to make that move yet.

How could we introduce a new, temporary permissions mechanism without breaking the existing system, but ideally making it easier to move to the better package later?

Ultimately, I decided to implement this new permissions system with essentially the same API as the package they eventually planned to move to.

This way, when we were ready to make the switch, it would be a simple refactor to replace our temporary system with the new package. And it would give us a chance to see how the new roles/permissions API would work in our project.

If it went well, perhaps more of the legacy system could be moved into this new permissions system, making that bigger refactor easier and easier with each chunk moved over.

Obviously, it wasn't as robust as the package would be. There wasn't a caching layer, and there weren't all the same features available for layering roles and permissions together. But the basic API was there, and would essentially be a drop-in replacement when we were ready.

I'm a big fan of taking on a hard project that needs to get done, but sometimes there are business constraints that make it impossible to take on that project in the short term.

With this approach, you at least are moving toward the eventual goal, even if you can't get there in one big change.

Here to help,

Joel

P.S. Do you have a big project you've been putting off? We are happy to help you get started.