Hi,
~ wrote:What are the best means of keeping track of the development stages of your project that have been proved by yourself to be effective so you don't forget what you did some time ago and being able to start with your development time?
My project is a little different than most in that it's very modular and there's distinct boundaries between the modules (i.e. they're seperate binaries).
In theory I write the documentation for a module (describing what it's meant to do and the interfaces it's meant to provide) before I begin writing the code. In practice I'm sloppy (the general design has become entrenched into my mind, and minor details can change during implementation) so I typically end up doing a rough draft then improve on it while I'm implementing the code and end up with about half the documentation I should have had.
~ wrote:Do you use heavy documentation? A very distributed source tree? Just a definition of source/object modules? Or do you use a combination of those and/or something else?
All modules are organised into a hierarchical tree of HTML pages, beginning with a brief overview of the project at the top of the tree and getting more and more detailed as you go down, until you reach source code at the ends. Because my source code is auto-converted into HTML the entire tree (all documentation and source) becomes my OS's web page.
To avoid forgetting what I did a long time ago I try to implement each module entirely before starting the next module. At the moment this means I'm working on boot code that parses ACPI SLIT tables and sorts out locality information for NUMA machines, even though I still haven't started any part of the kernel.
It seems slow and sometimes it's not possible to only work on one module, but there's very little back-tracking and (hopefully) very little rewriting.
As a comparison, it would be possible for me to skip a lot of things (SMP, NUMA, page colouring, full CPU detection, long mode, etc) and get a basic kernel running, but then I'd need to revisit everything I'd done and try to add support for new features that weren't originally considered. I've tried this method before and found that (for me) it causes large amounts of broken code (often followed by starting again from scratch).
Of course what works for me may not work for other people. For example, using version control software works for most people (but I hate it and prefer copying the project's directory every now and then).
Cheers,
Brendan