I had an enum representing the steps in a processing pipeline. Originally it was backed by integers, so sorting logged processing events in the proper pipeline order was straightforward in the database and application code.
But for reasons outside the scope of this tip, we needed to refactor to a string-backed enum instead.
With string backing, I lost the ability to do a simple numerical ordering, but we could instead use the natural ordering of enum cases in PHP.
SomeEnum::cases() returns them in declaration order, so I could derive the sequence from the enum itself without duplicating it anywhere.
The catch is that most teams, including ours, default to sorting enum cases alphabetically. It's a reasonable convention, and someone tidying up the codebase might "fix" the order without realizing it carries meaning.
My main defense to prevent this is to write tests that cover the full pipeline and verify that jobs are dispatched in the correct order. If someone rearranges the enum cases, the pipeline tests will fail, and the broken code will not make it to production.
But I also went a step further, and added a small two-line comment at the top of the enum explaining the significance of the case ordering. This tells the next developer that the order is intentional, not a sloppy deviation from a typical coding standard.
I know I talk about the importance of comments a lot, but little things like this go a long way to make a codebase easier to manage over time.
Here to help,
Joel
P.S. Want to talk through design decisions like this with other Laravel developers? Join our community.
Slack