Hi Frank,
Interesting thoughts. I have noticed the problem but thought it might
just be my own attitudes as I get older!
As I think about it, folks of my generation had to climb a very steep
learning curve just to write our first programs. I learned about
refactoring back in the 90s, by which time it seemed like a way to
make my work easier, not harder. The same was true for all the XP
practices at the time... but times have changed.
One thought on teaching this stuff... use at least some commonly
reversible refactorings. For example... convert to method vs convert
call to inline code. I talk about "forces" in this context, in the
same way I teach architectural patterns. In different contexts, the
forces want to resolve in different ways. When I make __choosing__ the
refactoring seem more intellectually challenging than doing it ('cause
it is!) I find that at least some folks start paying attention.
Another think I believe strongly is that folks should learn
refactoring first __without__ tooling to do it for them. Once they do
a few of them by hand, particularly if they are wide-ranging in the
code, they end up with a better understanding about what the tool
needs to do. This also gives the opportunity to talk about how the
presence of tooling changes the balance of the above forces. They also
need to learn about the danger of limiting oneself to only those
refactorings supported by the IDE.
Charlie
On Mon, Nov 25, 2019 at 1:59 AM Frank Carver via Groups.Io
<frank.carver@...> wrote:
I teach programming at the local university and have found that one of the biggest mental blocks which students need to overcome is the assumption that there is only one way to solve any problem, and that the job of a programmer is to find that way.
This mindset makes it really hard to teach refactoring, particularly in the context of eager new practitioners of TDD who want to rush on to the next test as soon as the first one passes.
I'm not sure where this attitude comes from. Perhaps the way that programming and/or software development has been reframed as "coding", and the implications of the name, or maybe that first experiences in the field often come from poking at HTML and CSS with a stick to get something that looks right, and then copy/pasting a bit of Javascript or PHP to make something happen, or perhaps the prevalence of fill-in-the blanks frameworks, or perhaps that so many students prefer to learn by following a linear set of steps from YouTube, Who knows
I'd love to investigate this in more detail, as I too, can see how much new developers struggle with the concept and skills of refactoring.
If it helps, I have found that I get slightly better traction if I lead with the idea of "code smells."
Frank Carver
