When considering significant design changes, we need to think about
several things:
1) The expected benefit
2) The expected cost in programming/debugging/testing and
documentation time
3) The effect on the code base (Which is really part of the cost):
a) Does the change make the code easier to understand or more
difficult?
b) Does the change add complexity, making it easier to break
things and create bugs?
c) Does the change move us towards or away from our long term goals?
Chris, would Dimitry's answering of the above questions help you
understand what he's trying to do?
And the most important thing for me is communication do that the design
become more clear and evident. So I shall try to work in this direction
and create some diagrams when I have time for it.
Perhaps, I should start to document the plugins, but I must do this
offline. Any proposals how to achive this
Dimitry has suggested that we use UML for documenting the design, I
believe. I think that's a pretty good approach, if the rest of the team
agrees. It would be really useful to have good UML documentation of the
system on the website. It would help new developers a great deal.
Ray
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Freemind-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freemind-developer
