On Wed, Jul 26, 2023 at 11:39?AM Vaughn Cato via <vaughn_cato=
[email protected]> wrote:
?
When I talk about a signal being weak, I mean that it isn't a strong indication that something must be done to correct it.
I believe I understand you better now. Indeed, I consider the signals "weak" in the same way, but then I change my expectation from "This code needs to tell me when a design change must be corrected" to "This code tells me when to pay closer attention to emerging design risks", and then it becomes more meaningful to me to evaluate signals for strength. What do you think about that?
?
The term "smell", I believe, was created to try to indicate that it's something that might be a concern, and is worth consideration, but if no clear general improvement is possible after some consideration, then no change is necessary. For example, if a function is long, then I'll look to see if I can find a natural way to break it up, but if after some consideration, it doesn't seem like breaking it up is going to make the code any clearer, or causes other issues, then I'll ignore that signal and continue.
That matches how I work.?
In this sense, I guess I'm saying that the strength of the signal is an indication of how much work I'm willing to do to remove the signal.
For me, the signals such as "I'm having to write a lot of test code to show what I'm trying to achieve" are much stronger, and I'll go to great lengths to avoid it. For example, I may break up a function to make testing easier, even if I wouldn't have broken it up just because it smelled like it was too long.
I believe I understand you. I guess you find yourself more sensitive to the design risk signals coming from the tests than coming from the production code itself. That surprises me, because I don't hear it very often, but it doesn't surprise me, because I tend to work similarly. I tend to hear the opposite: the typical programmer seems to pay little attention to the design risk signals coming from tests. That might be because I tend to work with programmers still drowning in defects, so they're usually too distracted to see the tests as a source of feedback about design choices.
?Thanks.
-- J. B. (Joe) Rainsberger :: ?:: ::
Replies
from this account routinely take a few days, which allows me to reply
thoughtfully. I reply more quickly to messages that clearly require
answers urgently. If you need something from me and are on a deadline,
then let me know how soon you need a reply so that I can better help you
to get what you need. Thank you for your consideration.
?
On Fri, Jul 21, 2023 at 9:56?PM Vaughn Cato via <vaughn_cato=
[email protected]> wrote:
?
I find that the design signals that I get directly during refactoring are actually pretty weak. There are code smells, but these aren't the signals. The code smells are things that you or other people have determined generally tend to make the design better, but this is just something that you recognize from experience.
What makes this "weak" for you? The signals can only say "Pay attention here!" I'm not sure they could ever say anything stronger than that.
But then, the signals from test runs can only say "Pay attention here!" as well. What makes them stronger for you than the "code smell"/"design risk" signals?
?
I find the actual design signals come about when trying to create a test or to make a test pass. I get strong signals such as "It's not clear to me how to make this pass", or "I'm having to make changes in a lot of places to make this pass," or "I'm having to write a lot of test code to show what I'm trying to achieve." This leads to me doing more preparatory refactoring than other kinds of refactoring, because the signals are strongest then.
I don't find those signals stronger nor weaker, but merely different. What makes them feel stronger for you?
J. B. (Joe) Rainsberger :: ?:: ::
Replies from this account routinely take a few days, which allows me to reply thoughtfully. I reply more quickly to messages that clearly require answers urgently. If you need something from me and are on a deadline, then let me know how soon you need a reply so that I can better help you to get what you need. Thank you for your consideration.
--
J. B. (Joe) Rainsberger :: :: ::
Teaching evolutionary design and TDD since 2002
--
J. B. (Joe) Rainsberger :: :: ::
Teaching evolutionary design and TDD since 2002
J. B. Rainsberger