I used to agree with #1, but I've since come to realise it was (at least in my case) an overreaction.
Now, my feeling is this. If you need to run some logic in a worker, just write it in the worker until your needs change. The one valid reason for extracting it is that it improves something – makes tests easier to write or faster to run, de-duplicates code avoiding bugs etc.
Also consider that the cost of extracting it to another class today (when you don't know how or if you will reuse it) is probably about the same as extracting it later if the need arises. And then you will only do it if you need to, and you will be able to do a better job since you know how it's reused.
It's always the case that it depends, of course. There are nuances and I'll extract some stuff, e.g. things that are very clearly tightly coupled to a model and has the same reasons to change as other parts of that model.
For small, straightroward workers, I agree with you that it could stay in the worker since we don't know how it would grow.
For workers with complex actions though, I think that #1 still applies since we already know more or less how the logic would grow, and enforcing that now could save other developers working on it in the future of having to figure out how it's supposed to be organized.
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.
I used to agree with #1, but I've since come to realise it was (at least in my case) an overreaction.
Now, my feeling is this. If you need to run some logic in a worker, just write it in the worker until your needs change. The one valid reason for extracting it is that it improves something – makes tests easier to write or faster to run, de-duplicates code avoiding bugs etc.
Also consider that the cost of extracting it to another class today (when you don't know how or if you will reuse it) is probably about the same as extracting it later if the need arises. And then you will only do it if you need to, and you will be able to do a better job since you know how it's reused.
It's always the case that it depends, of course. There are nuances and I'll extract some stuff, e.g. things that are very clearly tightly coupled to a model and has the same reasons to change as other parts of that model.
For small, straightroward workers, I agree with you that it could stay in the worker since we don't know how it would grow.
For workers with complex actions though, I think that #1 still applies since we already know more or less how the logic would grow, and enforcing that now could save other developers working on it in the future of having to figure out how it's supposed to be organized.