

Refactoring to clean code.  - handybitesize
http://www.amaxus.com/cms-blog/refactoring-to-clean-code

======
stephenjudkins
These are excellent examples of refactoring.

It's strange, however, that the author brings up the absolute necessity of
unit tests when refactoring like this, yet says he omitted them for brevity.
I've found, however that one of the most difficult and important parts of
refactoring is making sure code has proper test coverage, especially when
starting with crufty code. It's unlikely that the (not very clean) code he
presents came with a thorough set of unit tests.

The first thing I try to do when working with insufficiently tested code is to
begin refactoring it into a more testable form. This involves many small
steps, and in some cases manual testing to make sure that the automated tests
I'm writing are testing the correct thing. I think this article would be
better if he moved the parts conducive to that (#6 and #9) to the top and
included examples of writing tests (with appropriate mocks).

Further, canvas is a rich and complicated API that is relatively difficult to
test against; for this article something simpler might have been more
appropriate.

------
david_shaw
This is a phenomenal introduction to refactoring to clean code. A lot of young
developers with whom I interact tend to not understand the importance of
cleanly refactored code.

The hacker mentality, furthered perhaps by the prevalence of scripting
languages, allows people to think sometimes that "if it passes the test, it's
good for production!"

This is how amateur software projects die. I've seen it dozens of times: a
young, ambitious programmer starts promising project, creates a sort of mock-
up that runs (badly), and then tries to continue adding features and improving
upon the already-decaying codebase.

Refactor your code. Make things clean. Even if you _never_ plan on passing
your passion project on to another developer, it's important to understand
that without clean code even _you_ will be unable to understand and
efficiently work with your codebase.

This is one of the better introductory tutorials I've ever read, and the
hands-on example is excellent. Great read, and I've bookmarked it to refer
people to later.

------
sbov
It might be because the example is somewhat contrived, but am I the only one
who sometimes finds refactored code harder to understand or change? The final
version is "cleaner", but it also is twice as long, which means you have more
code you need to understand, and more text to sift through to find what you
need.

I often find the "many little functions" working against me. An abstraction is
beneficial if your task doesn't require seeing through that abstraction - but
otherwise it can be harmful. If I need to change something core to movement,
flap() and drop() aren't doing me any favors.

Unless theres other glaring issues, if a function is already less than 30
lines of code, I usually find a comment nicer than refactoring to yet another
method.

~~~
davnola
I prefer explanatory variable and method names to comments. Comments lie: they
cannot be specced or debugged, and few if any developers take responsibility
to edit and maintain comments made by others.

As a rule of thumb, I comment only when there is a surprising externality
relevant to the code e.g. performance, obscure workaround.

~~~
gruseom
In my observation, many programmers who advocate liberal commenting have no
discipline whatever when it comes to maintaining all those comments. That
ought to disqualify them from any debate on the subject. Unfortunately, except
for the few one has personally worked with, it's impossible to tell who they
are. :)

------
jtchang
I have a love-hate relationship with unit tests. They are great in theory but
in practice not enough people do it to reach that "critical-mass". By that I
mean very few projects you pick up (especially in the maintenance phase) will
have tests.

And writing good tests is HARD. If you think it is easy then you are testing
the wrong thing. A lot of people say refactoring without tests is pure danger.
I disagree. Sometimes you don't know enough about the problem space to write
good tests. However, refactoring forces you to understand the "micro" world of
the code. And this gives you a leg up in order to understand what tests are
actually needed.

~~~
eru
Do you have experience with QuickCheck? It allows you to specify rules and the
computer will generate the tests for you. That's very pleasant to work with in
languages susceptible to this kind of reasoning (e.g. Haskell).

(Edit: quicktest -> QuickCheck. Thanks!)

~~~
jholman
I suggest that you're thinking of <http://en.wikipedia.org/wiki/Quickcheck>

------
okaramian
I've been working on a project for the last year or so (on and off)
refactoring code and shifting it from Classic ASP to C#/.NET.

I'll say the one thing that would really help would be unit tests on the old
code. It's rough transitioning some dirty logic that seems to work from one
end to the other and not having a simple test to know I didn't break
everything upon refactoring.

~~~
xiongchiamiov
I have the book "Working Effectively with Legacy Code"[0], and it's pretty
much just "Put things under test, then change them.". Still a useful read,
though, if you find yourself working in that sort of thing often (I do).

[0]: [http://www.amazon.com/Working-Effectively-Legacy-Michael-
Fea...](http://www.amazon.com/Working-Effectively-Legacy-Michael-
Feathers/dp/0131177052/ref=sr_1_1?ie=UTF8&qid=1286321306&sr=8-1)

