Joerg Barfurth wrote:
[...]
As others have written: if you first look at an unknown project of
several million lines of code, the structure of which you don't know
yet, you'll see only spaghetti.
Yes, agreed.
I wondered how potential developers do get started. For example, I have
not done a documentation project for some time that required me to look
through the code for comments. Possibly if it was offered, I would
politely decline as there are many other more interesting things to do :)
At other times, I worked with the system architects and designers,
poured over specification documents and code analysis information. Then
hope there will not be too much change before we got to the final
implementation.
If I look at the resources collated on
http://wiki.services.openoffice.org/wiki/Main_Page I feel that you need
to be sure of your skills, know what it is that you want to do, and just
get straight to the code. Is this correct?
No UML diagrams or fluffly clouds. Do people still use these?
It also is the case that the code of OOo has evolved over some 15
years, most of it as closed source. In this time programming
techniques, particularly for C++, progressed a lot.
I guess it is important to note, that although we say that OOo is five
years old, that there is history that goes back even further.
As a result, you will find areas done at different times and by
differently skilled or trained people that exhibit code of varying
quality.
OK.
There are some areas that look relatively 'spaghetti'. We know about
them, because they are harder to change and prone to cause
regressions. And we are incrementally cleaning them up. But generally
just rewriting from scratch doesn't make everything better
automatically, because you lose the accumulated bug fixes and special
cases that were needed to make the code work in the real world.
It is good to know that the offending areas have been isolated. Are
these hidden from newer developers with appropriate signposts? Also, I
do hope that there are a number of collective heads that stick around to
work through these issues, or that they are properly documented.
And if you see how OOo evolved from 1.x to 2.0, you have living proof
that our code is not all that bad and unmaintainable.
It is good to hear this from a developer :)
BTW, most of the spaghetti-ish code is rather old and dates back to
the closed-source days. The code that was newly written since the
code was released on OpenOffice.org generally uses a more modern
style and is easier to maintain. So this proves the opposite of the
point of that researcher.
Yes.
Even more telling is what happened at mozilla.org where much unhard
to maintain Netscape code that had been developed as closed source
was scrapped to be replaced by better code from the open-source
developpers. It appears that closed-source programmers are more prone
to producing ugly code - under the pressure of schedules set by
management or simply because they think noone else will ever see that
code so they needn't be ashamed.
I used to have a book that showed an iceberg on the front cover. The
analogy was that software development was that part of the ice you could
see. Software maintenance represented most of what was under the water.
Being able to be creative in your own space is much more preferable.
Working with others in this way is also productive. I just wish that we
all had that opportunity if and when we wanted it :)
People keep saying that they need more developer resources without being
specific. Although some have mentioned documentation, others have said
there is so much documentation they don't know where to start.
Is there anything that you can think of that would assist potential
developers of varying skill levels (and perhaps commitment) to contribute?
Thank you for your feedback, Joerg.
Regards
Jacqueline
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
