Refactoring idea for buildShardFailures()?

Hi Sir/Madam,

I'm doing some research in automatic refactoring suggestion. By observing
the co-change pattern of some similar code, we would like to develop a tool
to suggest possible refactorings to apply in order to extract out common
code while parameterizing any difference between them.

I have examined the code snippets in class
org.elasticsearch.action.search.type.TransportSearchScrollScanAction.AsyncAction,
org.elasticsearch.action.search.type.TransportSearchScrollQueryAndFetchAction.AsyncAction,
and
org.elasticsearch.action.search.type.TransportSearchScrollQueryThenFetchAction.AsyncAction.

I notice that all of the three classes have method buildShardFailures()
defined. The method bodies are pretty similar and they experience similar
or same changes at least once in the version history. Do you think it is a
good idea or bad idea to extract a method out of the methods?

No matter whether you would like to extract a method or not, would you like
to share the factors in your mind which affect your decision, such as
complexity of refactoring, poor readability, poor maintainability, etc.? For
each factor, how do you think it can affect your decision about using
refactoring? If possible, any quantative analysis will be great. For
example, if the code size after refactoring is greater than that before
refactoring, I won't do refactoring. Or if there are only two lines shared
between two code snippets, I won't do refactoring, etc.

Thanks a lot for your help! Your suggestion will be very valuable for our
research.

Best regards,
Na Meng

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/24d9494b-c514-477b-8096-ae6dec8ca638%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.