In article
<58a6bb1b-a98e-4c4a-86ea-09e040cb2...@r35g2000prj.googlegroups.com>,
snorble <snor...@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.
--
http://mail.python.org/mailman/listinfo/python-list
