擬呈現(xiàn)當前js的組織方式餐曹，及對調(diào)整方向的幾個疑惑
目錄結(jié)構(gòu)
map_screen2/
|____cache.js
|____ctx.js
|____debug.js
|____fillers.js
|____grow.js
|____main.js
|____repair.js
|____screen.js
|____search.js
|____timer.js
其實此文件夾下的這所有文件預(yù)期是合并為一個js發(fā)布的（map_screens2.js）蜡塌。之所以拆開仑性，是為了每個文件對應(yīng)一個功能點军掂，好管理蠕搜。
發(fā)布的文件為4個頁面復(fù)用（www/m各自的24hour頁怎茫、自助報修頁）。當然妓灌，自助報修頁的地圖上呈現(xiàn)的不是“屏”轨蛤，而是“人”。偷懶了虫埂，沒有將代碼中“screen”替換為一個更泛的詞祥山，如“item”。見諒掉伏。
復(fù)用機制
代碼90%是一致的缝呕，需要區(qū)分處理的地方采用了最土的策略（if-else），例如：
// 坐標相關(guān)
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();
}
}
},
自白
- 其中代碼并不冗余
- 沒有用面向?qū)ο蟾ⅲ聘癫桓?/li>
- “拆開”岳颇？如何拆？有什么更“洋氣”的復(fù)用機制颅湘？（我所知的话侧，要想完全杜絕 is_www() / is_supplier_map() 等出現(xiàn)，可以將各自單獨的代碼放在單獨一個js中闯参，最終發(fā)布時只合并自己的瞻鹏，如上面代碼段將為：）
// 公共文件中：
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馏慨。人啊埂淮，太沒追求~~
向模塊化轉(zhuǎn)的痛點
私覺得：
- 用不用“洋氣”的復(fù)用機制，并不是此番模塊化過程中的關(guān)鍵影響因素写隶。
- 若按照immy框架下“標本”的做法倔撞，應(yīng)該將它們class化，并寫到一個js中（路徑如：SomeModule/main.js）慕趴，那個js將是無比大的痪蝇。形式上看來鄙陡，是清爽了；實際上躏啰，一個1000+行的js文件趁矾，維護起來必定是痛苦的。（immy框架是不是可以考慮引入“支持將main.js拆分成多個子js”機制给僵？）
- 目前已采用的方案（將以上js不作改動毫捣，照搬到iscripts/global/biz中），算是immy框架接納這類“不能徹底進化”的js的一種兼容想际、妥協(xié)之道培漏，我比較贊同溪厘。畢竟胡本，將這么“重”的邏輯代碼重新?lián)v騰一次，是有相當難度的畸悬。
- 另一個頁侧甫，屏詳情，情況類似蹋宦，且更復(fù)雜一些披粟。老代碼中，這兩個頁面是最復(fù)雜的冷冗。
