Lan Barnes wrote:
On Tue, October 23, 2007 7:10 pm, Andrew Lentvorski wrote:
Christian Seberino wrote:
Andrew Lentvorski wrote:
It is, by definition, faster. There is no point at which your system
has less functionality than it did before. This is not true for a
rewrite.
If an existing project is very modular with clean interfaces between
components then a rewrite of one piece at a time is possible...assuming
you
aren't changing the original design *too* much. I don't know if CVS was
a
big monolithic spaghetti blob.
It probably was.
So, you write a couple small unit tests and start to de-spaghetti.
The best way to write unit tests for a big system that doesn't have them
is to write unit tests *as you fix bugs*. The big advantage to this is
that the areas most prone to bugs wind up with the most unit tests.
Once you have enough accumulated unit tests, you can rewrite that
section of the code and have confidence that you didn't break anything.
-a
No no no nonono.
You forgot:
0. Don't break working code
1. user needs
2. requirements
3. design
4. iterate
THEN code
You cannot test quality into SW. It must be designed in.
At no point did I claim otherwise. This unit tests do not improve
quality, they simply point out the lack thereof.
However, without those unit tests, you cannot rip out poor quality
subsystems and do 1,2,3,4 and know that you aren't going backwards.
You can take a fundamentally broken design and throw it completely away
*as long as you have a full set of unit tests*. Unit tests are possibly
more valuable than the actual code base.
The problem with the "we'll rewrite it" bunch is that 99% of the time,
those systems *don't* have unit tests. Somehow, projects with good unit
tests never seem to enter a "we'll rewrite it" phase. Go figure.
Something about actually seeing a mountain of unit tests seems to scare
off the cowboy coders.
-a
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
