"I think the community needs more explicit direction...."
|
I would like to amplify Avi's comment below.
I have noticed something when programmers try to practise TDD: they don't seem to learn how to refactor. I don't mean to state this so harshly, but it seems that they struggle a lot more with refactoring than I did when I started. I have this feeling that "we" learned relatively quickly compared to what I see, even comparing myself programming in Java in 1999-2002 to today's programmer also working with Java. And today's Java programmers have better libraries and better tools! They use IDEA and Vavr, but I had Eclipse and plain Java. :)
I'd like to know your impressions. Which kinds of problems do people have when they try to learn how to refactor? When they learn how to guide a design to evolve? Why does it seem like they have more difficulty learning this than "we" had?
I admit that I probably have some strong cognitive distortion. That's why I'm asking this question.
Cheers, -- J. B. (Joe) Rainsberger :: :: :: ---------- Forwarded message --------- From: Avi Kessner <akessner@...>Date: Thu, Nov 14, 2019 at 5:05 AM Subject: Re: [testdrivendevelopment] We are back on the air! To: < [email protected]> Is this the diagram you wanted to share?
I would recommend making a box which is part of the flow rather than some external dotted lines. For example, maybe the box should read, " Apply SOLID principles" as part of the refactoring, and then before the next failing test have something like, "design the contract"
I think the community needs more explicit direction on the design being done in those phases.
On Tue, Nov 12, 2019 at 11:27 AM Roy Osherove < roy@...> wrote: ? Awesome.? I sent a new thread to the group about tdd diagrams.? Was it received?
Maybe.
If you sent it to the Yahoo! group, then no.
Please try again--at least until we figure out the transition. :) I want to see it! -- J. B. (Joe) Rainsberger :: :: ::
|
