拟呈现当前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();
}
}
},
自白
- 其中代码并不冗余
- 没有用面向对象，逼格不高
- “拆开”？如何拆？有什么更“洋气”的复用机制？（我所知的，要想完全杜绝 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。人啊，太没追求~~
向模块化转的痛点
私觉得：
- 用不用“洋气”的复用机制，并不是此番模块化过程中的关键影响因素。
- 若按照immy框架下“标本”的做法，应该将它们class化，并写到一个js中（路径如：SomeModule/main.js），那个js将是无比大的。形式上看来，是清爽了；实际上，一个1000+行的js文件，维护起来必定是痛苦的。（immy框架是不是可以考虑引入“支持将main.js拆分成多个子js”机制？）
- 目前已采用的方案（将以上js不作改动，照搬到iscripts/global/biz中），算是immy框架接纳这类“不能彻底进化”的js的一种兼容、妥协之道，我比较赞同。毕竟，将这么“重”的逻辑代码重新捣腾一次，是有相当难度的。
- 另一个页，屏详情，情况类似，且更复杂一些。老代码中，这两个页面是最复杂的。
