Development tools and practices for Pythonistas

[Roy Smith]

In article 
<58a6bb1b-a98e-4c4a-86ea-09e040cb2d21 at r35g2000prj.googlegroups.com>,
 snorble <snorble at hotmail.com> wrote:

> [standard tale of chaotic software development elided]
>
> I am aware of tools like version control systems, bug trackers, and
> things like these, but I'm not really sure if I need them, or how to
> use them properly.

None of this has anything to do with python.  It's all standard software 
engineering stuff that's the same with any language or technology.

Bug trackers are essential for large projects.  For a one-man project, 
it's probably more effort than it's worth.  For the project I'm on now 
(4 developers co-located with the customer), we're using a shared google 
docs spreadsheet for bug tracking.  It's free, low-overhead, and works 
well enough.  For a single person, even that may be more than you need.

On the other hand version control is essential from day zero, even on a 
one-man project.  There's plenty of perfectly good, free, systems out 
there.  The obvious choices are hg, git, and bzr.  Pick one and use it.  
The nice thing about them all is there's no lock-in.  If you decide you 
don't like the one you're using, you can easily convert your entire code 
repository to any of the others without losing anything.

> I really like the idea of having a list of features, and tackling
> those features one at a time.

Yup, that's the core concept of all the agile development processes that 
are all the rage these days.  Sometimes called "release early and often".

> I read about people who do this, and
> each new features gets a new minor version number.

For the project I'm on, we don't even bother with version numbers.  We 
have a main branch which we (try to) keep stable and shippable at all 
times, and push that to production whenever we've completed a feature 
(or bug fix) that the customer needs.  I see we're currently running:

9be3fc6a0e01cf128f63d1af2b19c180fb4eaacb (tip)

Version numbers make more sense with a traditional ("waterfall") type 
process, where you design a bunch of stuff, write the code, go through a 
testing and bug-fixing cycle, and the finally push it out the door.


> I think I just need some recommendations to help
> create a good mental map of what needs to happen, and mapping jargon
> to concepts. Like, "each feature gets its own directory". Or with a
> version control tool, I don't know if a feature maps to a branch, or a
> commit?

Well, start from the premise that you have a main branch which is always 
shippable.  That means the code runs and passes all the tests after 
every single commit to that branch.

Now, when you need to make a change (add a feature or fix a bug), ask 
yourself if the change is small enough that you can do all the work 
required in one day.  If so, then doing it in a single commit on your 
main branch may make sense.  If not, then spin up a development branch, 
do the work there, and when you're satisfied it's shippable, merge it 
onto your main branch.