Should I use "if" or "try" (as a matter of speed)?
peter at engcorp.com
Tue Jul 12 14:21:09 CEST 2005
Edvard Majakari wrote:
> "first make it work, then make it right, then make it fast"
> Shouldn't one avoid doing it the wrong way from the very beginning? If you
> make it "just work" the first time, you'll probably use the old code later on
> because "functionality is already there" and temptatation to build on probably
> relatively bad architecture can be too strong.
The expression describes (most recently, if not originally) the practice
in Test-Driven Development (TDD) of making your code pass the test as
quickly as possible, without worrying about how nice it is.
The "right" part doesn't refer to correctness, but to structure, style,
readability, and all those other nice things that an automated test
can't check. You aren't doing it "wrong" at first, just expediently.
And it really does make sense, because at that early stage, you aren't
even absolutely certain that your test is entirely correct, so making
your code a paragon of elegance is a potential waste of time, and
distracting. Once you've been able to pass that test (and all the
others, since you have to make sure all previous tests still pass as
well), then and only then is it sensible -- and required! -- to refactor
the code to make it elegant, concise, clean, etc.
Of course, your point about temptation is sound. Extreme Programming
tries to avoid that problem partly by pairing programmers together, and
it is the responsibility of both partners to encourage^H^H^H^H^H insist
that the refactor "make it right" stage must occur _now_, before we
check the code in. If you skip this step, you're failing to be an agile
programmer, and your code base will become a tar pit even more quickly
than it would in a traditional (non-agile) project...
More information about the Python-list