For me, personally, it depends on whether the non-dry stuff is a true repetition of business logic, of the domain specific stuff, of the requirements set forth by end users.
If people in the business give it a name ("the user registration process", "subscribing to a tag") it must be dry, even if only used twice, to avoid bugs.
If the repetition however is due to composition, further abstraction often hurts the code. You might often remove the first item of array, then filter invalid stuff, then reduce it to an aggregate — doesn't mean it must hide inside a tailFilterInvaludReduce() method. Leaving the composable bits composable is often a good thing, because method names can lie about their contents.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
For me, personally, it depends on whether the non-dry stuff is a true repetition of business logic, of the domain specific stuff, of the requirements set forth by end users.
If people in the business give it a name ("the user registration process", "subscribing to a tag") it must be dry, even if only used twice, to avoid bugs.
If the repetition however is due to composition, further abstraction often hurts the code. You might often remove the first item of array, then filter invalid stuff, then reduce it to an aggregate — doesn't mean it must hide inside a tailFilterInvaludReduce() method. Leaving the composable bits composable is often a good thing, because method names can lie about their contents.