-
Notifications
You must be signed in to change notification settings - Fork 411
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OAK-11214 Support 'IN' restrictions for functions #1813
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Just a single remark.
* | ||
* @return true, except when backward compatibility for OAK-11214 is enabled | ||
*/ | ||
default public boolean getOptimizeFunctionInList() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
to improve clarity and readability, can we rename this with something like:
isOptimizeFunctionInListEnabled
isFunctionInListOptimized
useOptimizedFunctionInList
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I also don't like the function name :-) Just a few points:
- FYI this method isn't supposed to be called anywhere except for the current code. And I hope we can remove the toggle in about a year or so.
- All the current getters have the "get" prefix (including boolean) so I think "get" is best.
- I wanted to use "getOptimize" first because I think we will soon have more of those "getOptimizeXYZ". So these methods have a similar prefix.
- I think no matter what the name is, it can not really convey what this is about... one basically has to read the Jira issue to understand the problem.
Said that, what about the following alternative: getOptimizeInRestrictionsForFunctions()
? It is longer, but is it better?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, it looks better.
On this point:
And I hope we can remove the toggle in about a year or so.
the article below has an interesting section on Managing the carrying cost of Feature Toggles
:
Savvy teams view the Feature Toggles in their codebase as inventory which comes with a carrying cost and seek to keep that inventory as low as possible. In order to keep the number of feature flags manageable a team must be proactive in removing feature flags that are no longer needed. Some teams have a rule of always adding a toggle removal task onto the team's backlog whenever a Release Toggle is first introduced. Other teams put “expiration dates” on their toggles. Some go as far as creating “time bombs” which will fail a test (or even refuse to start an application!) if a feature flag is still around after its expiration date.
https://martinfowler.com/articles/feature-toggles.html#WorkingWithFeature-flaggedSystems
No description provided.