On Wed, 31 Mar 2010 15:20:37 -0400
"C. Michael Pilato" <cmpil...@collab.net> wrote:
> For me, the biggest lessons to be learned here
> touch on over-engineering and under-testing.
As a mere user, who has tried to figure out where the bugs that
bit him are coming from (ie as someone who actually tried to
debug svn), I can tell you that there is not only a touch of
over-engineering but that svn suffers largely from it. Especially
the need to abstract everything at least half a dozen times, so
that you have to deal only with the abstract notion of something
you might have some abstract relation to some abstract thought
that could be comming from some actual implementation is highly
confusing and makes reading the code nearly impossible for someone
who has not had a month time to learn how the architecture of svn
looks like.
If you are ever going to refactor some of the architecture,
my advice would be to get rid of as many abstractions as possible
and use only those that are necessary to handle those few cases
where you actually have different implementations.
You can always add a new abstraction layer later, when you have
the need for it. But generally it is a bad idea to just make
an abstraction for something that someone, somewhen might want
to do differently.
Attila Kinali
--
If you want to walk fast, walk alone.
If you want to walk far, walk together.
-- African proverb
