[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