librelist archives

« back to archive

Refactoring exercises

Refactoring exercises

From:
Peter Minten
Date:
2015-03-07 @ 10:23
Hi all,

Currently all exercises are of the form: here's a problem and a test 
suite, write code that fixes the problem and that looks good to boot.

What if we'd do things differently for some exercises: here's a problem, 
a test suite and awful code that passes the test suite, clean up the 
code. In other words start with a functional but ugly solution and focus 
purely on the refactoring.

The big benefit I see for this kind of exercise is that it takes the 
mind of the user away from the builders mindset and into more of an 
aesthetic mindset. There's no need to burden your working memory with 
every little details of how the code should function so you can focus 
more on the design aspects.

One of the core rules of refactoring is making the smallest possible 
change that doesn't break anything and then running the unit tests 
again. A simple way to get people in the right mindset for this could be 
to ask them to keep a log of their refactoring steps. I don't think 
that's necessarily the best way to teach refactoring but it doesn't 
require any code changes to exercism.

What do you folks think? Would such exercises fit in with exercism?

Greetings,

Peter

Re: [exercism] Refactoring exercises

From:
Katrina Owen
Date:
2015-03-09 @ 13:58
On 03/07, Peter Minten wrote:
> What if we'd do things differently for some exercises: here's a problem, 
> a test suite and awful code that passes the test suite, clean up the 
> code. In other words start with a functional but ugly solution and focus 
> purely on the refactoring.

I think this would be hugely beneficial. People have asked me for a
refactoring "track" on exercism, but I couldn't figure out how to do a
separate track, since we would need a separate track for each language
in that case.

This is much better.

In many ways nitpicking is kind of a refactoring track, since it
requires you to look at existing code and imagine ways in which it could
be better, however I really like the idea of having explicit refactoring
problems.

> One of the core rules of refactoring is making the smallest possible 
> change that doesn't break anything and then running the unit tests 
> again. A simple way to get people in the right mindset for this could be 
> to ask them to keep a log of their refactoring steps. I don't think 
> that's necessarily the best way to teach refactoring but it doesn't 
> require any code changes to exercism.

I think that this is a good step in the right direction.

I've taught refactoring by creating a restraint that they must always be
"one undo away from green", meaning that if they get a failing test they
need to back out the change they just made and try again in a different
way. It's pretty extreme, and doesn't work in all languages, but it has
been very effective at teaching people how small a "safe" step can be.

We could think about writing a tool that would capture the state of the
code and tests every time a file was saved, but that seems like a very
different type of experience, and it would require a very different
web interface to discuss the process. I'd prefer to keep this simple.

> What do you folks think? Would such exercises fit in with exercism?

I think this would fit very well with exercism.

Katrina

Re: [exercism] Refactoring exercises

From:
Matthew Marcus
Date:
2015-03-09 @ 14:09
De-lurking just long enough to say I love this idea. I do find it
frustrating in exercism when I hit a brick wall because I don't know how to
solve the problem in the first place; it always struck me that this seems
like a completely separate issue to "how do I make code as elegant as
possible". And then I usually end up submitting the first that passes the
tests, just to get feedback on whether it's even the *right* solution, and
the elegance which should have been my primary objective has gone to the
wall.

A refactoring track/whatever would take a lot of the pressure off (by
saving hours of research for me in some cases). Finally, carte blanche to
absolutely prioritise the aesthetics of the thing!

On Mon, Mar 9, 2015 at 1:58 PM, Katrina Owen <_@kytrinyx.com> wrote:

> On 03/07, Peter Minten wrote:
> > What if we'd do things differently for some exercises: here's a problem,
> > a test suite and awful code that passes the test suite, clean up the
> > code. In other words start with a functional but ugly solution and focus
> > purely on the refactoring.
>
> I think this would be hugely beneficial. People have asked me for a
> refactoring "track" on exercism, but I couldn't figure out how to do a
> separate track, since we would need a separate track for each language
> in that case.
>
> This is much better.
>
> In many ways nitpicking is kind of a refactoring track, since it
> requires you to look at existing code and imagine ways in which it could
> be better, however I really like the idea of having explicit refactoring
> problems.
>
> > One of the core rules of refactoring is making the smallest possible
> > change that doesn't break anything and then running the unit tests
> > again. A simple way to get people in the right mindset for this could be
> > to ask them to keep a log of their refactoring steps. I don't think
> > that's necessarily the best way to teach refactoring but it doesn't
> > require any code changes to exercism.
>
> I think that this is a good step in the right direction.
>
> I've taught refactoring by creating a restraint that they must always be
> "one undo away from green", meaning that if they get a failing test they
> need to back out the change they just made and try again in a different
> way. It's pretty extreme, and doesn't work in all languages, but it has
> been very effective at teaching people how small a "safe" step can be.
>
> We could think about writing a tool that would capture the state of the
> code and tests every time a file was saved, but that seems like a very
> different type of experience, and it would require a very different
> web interface to discuss the process. I'd prefer to keep this simple.
>
> > What do you folks think? Would such exercises fit in with exercism?
>
> I think this would fit very well with exercism.
>
> Katrina
>

Re: [exercism] Refactoring exercises

From:
Peter Minten
Date:
2015-03-09 @ 16:43
On 03/09/2015 02:58 PM, Katrina Owen wrote:
> On 03/07, Peter Minten wrote:

>> One of the core rules of refactoring is making the smallest possible
>> change that doesn't break anything and then running the unit tests
>> again. A simple way to get people in the right mindset for this could be
>> to ask them to keep a log of their refactoring steps. I don't think
>> that's necessarily the best way to teach refactoring but it doesn't
>> require any code changes to exercism.
>
> I think that this is a good step in the right direction.
>
> I've taught refactoring by creating a restraint that they must always be
> "one undo away from green", meaning that if they get a failing test they
> need to back out the change they just made and try again in a different
> way. It's pretty extreme, and doesn't work in all languages, but it has
> been very effective at teaching people how small a "safe" step can be.
>
> We could think about writing a tool that would capture the state of the
> code and tests every time a file was saved, but that seems like a very
> different type of experience, and it would require a very different
> web interface to discuss the process. I'd prefer to keep this simple.

What we could do is have some kind of help page for refactoring problems 
where we discuss how to approach refactoring and what tools can help. 
For example if you commit every logically separate change in git with a 
meaningful commit message then your commit log will automatically be a 
log of the changes you did. Or one could use a tool like quilt to manage 
a stack of patches.

A side benefit of this approach would be to encourage people to learn 
about version control.

Greetings,

Peter