[Cosmo-dev] Refactor of cal_main.js
Matthew Eernisse
mde at osafoundation.org
Tue Aug 15 11:08:02 PDT 2006
Brian Moseley wrote:
> how is extracting the current code into separate files going to help a
> future redesign? does chopping up the code like this help you get a
> better handle on what's there? seems like you have a pretty good idea
> already.
>
That's a good point. The main reasons I initially approached the
refactoring this way were:
1. Breaking up the Cal object into those separate areas of functionality
has to happen anyway to accommodate the architectural changes.
2. Much of the code will not actually change (e.g., the
conflict-resolution code, the position-calc code, etc.)
3. It will make it easier to do serious refactoring (with multiple
people working, hopefully).
4. I am just most comfortable working in an iterative way. It lets me
focus on a single change or type of change at a time, and reduces
confusion about why something is broken.
> it looks like you've done a good job of listing all the different
> responsibilities of the existing code. why don't we sit down and work
> out how to assign those responsibilities to different classes and map
> out their collaborations? i think this will address the real need,
> whereas simply partitioning code into different files won't achieve
> any real benefit and will just add more import statements.
I'm sure open to other approaches -- I just like to work in an iterative
and incremental way, rather than doing a big rewrite up-front. To me
part of the benefit of simply breaking the code up is that it gets us
closer to the design we want.
But yes, I think a good whiteboard discussion would be really helpful
before diving in. There may be changes that it would make sense to
implement as I'm in the process that would also get us closer.
Matthew
More information about the cosmo-dev
mailing list