[BioPython] BioEutils

[Brad Chapman]

Hi Peter;

> I really appreciate your efforts. And by the way I can never be 
> disappointed with biopython modules that have problems, especially the ones 
> you write, you are always supporting them well.  I will load the module 
> from the public CVS and try again. If I come across how to escape the ":" I 
> will let you know.

Thanks for the kind words. Glad it worked for you.

> I have looked through the code and it looks like a massive work. I would 
> like to know your approach to planning a module like this and what is the 
> way in which you cycle through coding and testing?
> 
> I try to plan with  one or two diagrams (and I mean a few, as one can get 
> wrapped up in making pretty pictures), then try to use more of an extreme 
> programming approach (not strictly as some might want), except I am coding 
> as 1. I am interesting in knowing how you plan your project before coding.

Actually, the EUtils module was written by Andrew Dalke -- I'm only
providing the fixes -- so he could probably give you more
information about his programming philosophies.

As for me, I normally take the approach that you suggest. First I
try to come up with the requirements and goals, as I can figure them, 
for a module. In this regard, I tend to be much less thorough then
they teach you in programming classes (since I find too much
modeling kind of boring and prefer to get to programming). In
general, I just try to do the best I can to get a scope of the
project and design decent objects to start with.

>From there, I just program, and see what problems come up. So yeah,
extreme programming. In my experience no matter how hard I try to
come up with all of the requirement for my module, I'll run into
bits I never thought of as I program. Or similarly, requirements
change once you get into things. This will eventually require
re-programming of objects to make them more flexible. In this
regard, designing objects using well known design patterns often
helps ease the painfulness of the rewrites and updates. Sometimes,
however, you just need to scrap parts and re-code them when you find
out you haven't been general enough in your design to adapt objects.

Optimizing the planning and re-programming parts is the hardest part
of the work, and is not something I can claim to have any kind of
firm grasp on. Python is really nice in making the re-writing parts
less painful, at least in my experience.

As far as the testing, it ideally should be done throughout the
whole process. I find it easier to get a skeleton bit working and
tested and build on it from there, rather than try to code it all
and then debug it with tests. Balancing the scope of the tests with
the need to get the module done in some reasonable time is another bit
that is tricky.

Not much of a programming philosopher, but I hope this helps a bit
in your designs.

Brad