I am currently reviewing a PR where we want to enable a feature based on some suscription date of a user such as:
let featureEnabled = false
if (user.createdAt > MONETIZATION_DATE) {
featureEnabled = true
}
You get the idea. When reviewing changes like this, I usually suggest to make it not dependent on a date but on a feature of the user instead. Here is a possible rewrite following this idea:
let featureEnabled = false
if (user.referralVersion === 'V3') {
featureEnabled = true
}
Note: The referral program is the actual use case I have
The reasons for this suggestion are:
- We don't want the code to change it's behavior after some date automatically. It makes it difficult to reason about some behavior that was different from one user to another.
- If we accept this kind of pattern, looking 5 years headed, we could have the whole codebase depending on 50 dates were we wanted to change something. And the associated behaviors would be scattered everywhere in the code.
However, we can argue about my points:
- 5 years in the future is probably 4.5 years too far (we are an early-stage startup)
- The business requires this change from the actual date so it makes sense for the code reflect this change (that is part of our terms of condition)
- Making the switch depending on the condition requires some manual trigger the day we want to enable the feature, which is error-prone.
How do you usually tackle similar cases? Do you see other pros and cons I did not mention?
MONETIZATION_DATE
is a hard calendar date, and the createdDate field is a user subscription date. Does it answer your question ?