合并之惑——“地图屏列表js”

拟呈现当前js的组织方式，及对调整方向的几个疑惑

目录结构

map_screen2/
|____cache.js
|____ctx.js
|____debug.js
|____fillers.js
|____grow.js
|____main.js
|____repair.js
|____screen.js
|____search.js
|____timer.js

其实此文件夹下的这所有文件预期是合并为一个js发布的（map_screens2.js）。之所以拆开，是为了每个文件对应一个功能点，好管理。

发布的文件为4个页面复用（www/m各自的24hour页、自助报修页）。当然，自助报修页的地图上呈现的不是“屏”，而是“人”。偷懒了，没有将代码中“screen”替换为一个更泛的词，如“item”。见谅。

复用机制

代码90%是一致的，需要区分处理的地方采用了最土的策略（if-else），例如：

    // 坐标相关
    offset_map: function() {
        if (is_www()) {
            if (is_supplier_map()) {
                return this._offset_map_supplier();
            } else {
                return this._offset_map_www;
            }   
        } else {
            if (is_supplier_map()){
                return this._offset_map_m_supplier();
            }else{
                return this._offset_map_m();
            }   
        }   
    },  

自白

1. 其中代码并不冗余
2. 没有用面向对象，逼格不高
3. “拆开”？如何拆？有什么更“洋气”的复用机制？（我所知的，要想完全杜绝 is_www() / is_supplier_map() 等出现，可以将各自单独的代码放在单独一个js中，最终发布时只合并自己的，如上面代码段将为：）

// 公共文件中：
offset_map: function() {
    return screen_offset();
}

// www_hour24_map_cfg.js （www端24hour页只引用此js，下同）
function screen_offset() {
 // return the-data; 
}

// m_hour24_map_cfg.js
function screen_offset() {
 // return the-data; 
}

// www_supplier_map_cfg.js
function screen_offset() {
 // return the-data; 
}

// m_supplier_map_cfg.js
function screen_offset() {
 // return the-data; 
}

当初也想过这样，以让代码在概念上更清晰。但懒惰了，觉得建那么多文件麻烦，也使本来相似的代码分离开来，不好参照，就用了最土的if-else。人啊，太没追求~~

向模块化转的痛点

私觉得：

1. 用不用“洋气”的复用机制，并不是此番模块化过程中的关键影响因素。
2. 若按照immy框架下“标本”的做法，应该将它们class化，并写到一个js中（路径如：SomeModule/main.js），那个js将是无比大的。形式上看来，是清爽了；实际上，一个1000+行的js文件，维护起来必定是痛苦的。（immy框架是不是可以考虑引入“支持将main.js拆分成多个子js”机制？）
3. 目前已采用的方案（将以上js不作改动，照搬到iscripts/global/biz中），算是immy框架接纳这类“不能彻底进化”的js的一种兼容、妥协之道，我比较赞同。毕竟，将这么“重”的逻辑代码重新捣腾一次，是有相当难度的。
4. 另一个页，屏详情，情况类似，且更复杂一些。老代码中，这两个页面是最复杂的。