[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Is a ChangeLog file realistic if /lots/ of developers adding /lots/
From: |
cs |
Subject: |
RE: Is a ChangeLog file realistic if /lots/ of developers adding /lots/ of changes? |
Date: |
Wed, 25 Jun 2003 13:57:26 -0700 |
This overhead will take work and commitment from people. How much improvement
can this deliver?? 10%? 50%? 500%?
Is this advice meant only for large (>10? >100?) development groups???
The reason I am asking is that I usually work on projects with <10
developers. Things usually get done somehow regardless.
(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")
Chris
> -------- Original Message --------
> Subject: Re: Is a ChangeLog file realistic if /lots/ of developers
> adding /lots/ of changes?
> From: "Thien-Thi Nguyen" <address@hidden>
> Date: Thu, June 19, 2003 9:04 am
> To: address@hidden
> Cc: address@hidden, address@hidden
>
> address@hidden:
>
> If you have any advice or ways to streamline the process I would
> very
> much like to hear it.
>
> spend one hour a week as a group reading change logs (and only change
> logs -- no code!) for the week preceding. discuss applicability of
> changes, especially whether or not the change introduces new problems.
> note change/changeback pairs. characterize and categorize changes to
> determine if a larger-scope redesign is indicated (or rather, soon to
> be
> indicated :-).
>
> over time, this will streamline things because your group will be able
> to recognize useless (or less than optimal) changes that should never
> have been made in the first place, and thus reduce that kind of noise.
> you might also develop ability to pre-emptively figure out more direct
> and more robust changes to make.
>
> basically, to understand the code is one thing, to understand how you
> change your code is the next best thing, and to understand how you
> understand how you change your code is the best thing. change logs
> can
> help you do this.
>
> thi