Martin P. Hellwig
mhellwig at xs4all.nl
Sat Jul 28 15:43:14 CEST 2007
Kenneth Love wrote:
> That should teach me not to change working code at the same time I am
> writing unit tests. Even so, I realize it won't be the last time I
> do something so silly. Yes, I know about TDD's "write the test first",
> but I'm not comfortable with the philosophy of these new fangled unit
> tests yet.
I've been using python for about 3 years now, it was the first
programming language I learned and I haven't done any other since (well
that is if you dismiss sql and shell scripting on various platforms).
Though in my daily job I have some coding tasks, I do not see my self as
a programmer since in my perspective a programmer is someone who can
write good code regardless of the language. My code isn't any good, it
is barely functional (so I really needed unit-test way of coding, for my
own protection and not even because it gives more maintenance security
for the project).
But the funny thing that I have seen in the development scene is that
writing tests first and code later is a lot easier when you have a
technical specification to base it on. A technical specification is of
course based on a functional design. A functional design is written on
the base of the assignment and the scope definition.
The scope and design can change in the course of the project but good
practice is usually to do changes in another release. And that is what
software change management and release management is for.
Still there are tons of reasons why you shouldn't follow blindly the
best practice, since best practice is founded on theory molded around
the most occurring reality. And the only thing that I am absolutely sure
of is that reality differs enough from person to person and situation to
situation, that forcing the same practice to every person/situation is a
guarantee for wasting time and energy.
IMHO there are two extreme basic types of programmers, on the left are
the ones that have a problem them self, solve it while happily hacking
along the way, leaving the design part for a later stage, on the right
are people that know beforehand on an almost bit level what a program is
supposed to do, already have a design and aren't really that interested
in the problem that their code should solve in the first place.
Me I am a bit schizophrenic, I move in between of them, on a hourly
base. So for me the reality is that I have a certain 'problem' I write
some code with the built-in IDLE mostly following functional coding
practice (since I still have to figure out how some stuff works in
Then when I have a an idea what I am doing, I create a new project tree
in subversion and write my technical specification (still having IDLE
open to test some of the wild ideas that pop-up along the way).
After that I open Eclipse/PyDEV and start working on the unit-test and
follow from there, when the code is finished I check it in and branch it
as 0.0.1. Sleep over it and probably refactor it later on because I
didn't like some variables names and want to add some comments in the
code or move out some code to other classes, etc. etc.
The only problem is that I wish I was a bit more stable, because several
times it has happend that I thought that the problem is a one-liner, so
skipped the whole part after the figure-out-the-problem-code and used
that what I have already written. Sometimes that works out well, but if
it doesn't it always bites me hard.
But all these are just experiences from my side, I have no idea whether
I am right or not, but for me it seems to work, so don't take it as
advice (I am not really the person to take advice from) but as a little
'story' along the way :-)
More information about the Python-list