[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Is a ChangeLog file realistic if /lots/ of developers adding /lots/
RE: Is a ChangeLog file realistic if /lots/ of developers adding /lots/ of changes?
Thu, 26 Jun 2003 15:02:04 +0200 (CEST)
On Wed, 25 Jun 2003 address@hidden wrote:
> This overhead will take work and commitment from people. How much
> improvement can this deliver?? 10%? 50%? 500%?
Let me put it this way: writing Changelogs, though it does take a
commitment, has saved me (personally) a lot of time. I've been able to
speed up my development a lot, mostly because the debugging stage, which
invariably follows the development stage, is a lot shorter: using the
Changelogs, I already know what to look for and because I add a regression
test for every bug I kill, bugs are rarely revived before a checkin.
This *does* make for big regression test suites and it *does* mean I have
to write a Changelog for every non-trivial change (indenting is the only
trivial change as it doesn't change the code as seen by the compiler, but
sometimes it ends up in the Changelog anyway).
I also make sure that the Changelog only contains things related to
eachother - i.e. I don't mix changes in a single patch. This helps finding
related bugs (a lot).
> Is this advice meant only for large (>10? >100?) development groups???
No. I work alone most of the time - the other developers are usually users
of what I do.
> The reason I am asking is that I usually work on projects with <10
Makes no difference whatsoever.
> Things usually get done somehow regardless.
So do bugs.
> (I got a bad deal when I went crazy about OOP and decided to do
> everything object oriented only to discover that small projects don't
> necessarily benefit from OOP. Sometimes OOP can even *slow down* a
> little project. I hope this ChangeLog business is not another "OOP")
OOP is a whole other samba: it helps in architectures of big projects to
keep the conceptually clean, but it can only slow things down on the
performance end. There is *nothing* as fast as a big main() with as little
as possible function calls and comparisons, but it is *hell* to maintain
such a beast.
Changelogs should be seen as a weapon in the war against bugs - it's a
weapon you have to keep bright & shiny in order for it to work, but it is
a very effective one. Remember: bugs are pesky little critters that like
to hide in plain sight and especially feed on big projects but like the
smallers ones just as well. The only way to treat them is to kill them and
the only way to prevent them is by meticulously coding against bugs and
applying a bug-prevention strategy - Changelogs are part of that strategy.
Then there's always the "evolutionary" way of looking at things:
Changelogs help track the evolution of your project and see what needs
work. If you find you're working around a misfeature or a lack of feature
in your project a lot, your Changelog will show that and you'll know what