Skip to content
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

Merged
merged 4 commits into from
Oct 22, 2024
Merged

Conversation

thomasmueller
Copy link
Member

No description provided.

Copy link
Contributor

@fabriziofortino fabriziofortino left a 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() {
Copy link
Contributor

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

Copy link
Member Author

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?

Copy link
Contributor

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

@thomasmueller thomasmueller merged commit 2031e44 into trunk Oct 22, 2024
1 of 2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants