最近三個月我們一直在不斷調整前端結構，目的在于提升 前端開發的一致性和復用性，先后提出了 前端結構 の 調整建議（v1），前端結構 の 調整新建議（v2）。
最近兩周，基于 Jimmy 的實踐經驗，與目前團隊不斷的交流融合，在 6月24日，我們有了新共識，到達了一個新的里程碑。
原則
- 可理解性是首要的，通過明確的約定以保持良好的一致性；
- 創建和業務相關的 典型案例，便于團隊模仿、學習和理解；
- 鼓勵嘗試，容忍犯錯，凝聚團隊共識，漸進改造現有代碼；
三個頂級目錄
- imodules 模塊；
- ipages 頁面；
- iscripts 腳本；
目錄結構示例
├── imodules/
│ ├── base/
│ ├── embed/
│ ├── hour24/
│ ├── repair/
│ └── xbase/
├── ipages/
│ ├── home/
│ └── repair/
└── iscripts/
├── immy/
├── vendor/
└── xlibs/
imodules（模塊）
模塊劃分目的在于將復雜問題進行分解，提升獨立性，降低耦合度，促進復用，并行開發，以提升開發效率。
imodules
├── base
│ └── _baseUModules
├── embed
│ ├── EmbedBottom
│ └── EmbedTop
├── hour24
│ └── Hour24Matte
├── repair
│ ├── RepairMatte
│ └── RepairScreenSelect
└── xbase
└── _Matte
模塊分類目錄約定
1. 小寫字母開頭，駝峰風格，不使用中劃線和下劃線進行區隔，慎用數字；
2. 僅為源碼分類使用，不在 dist 發布目錄上體現；
3. 支持多級分類目錄；模塊實體目錄約定
同時作為模塊 id（元素 id），大寫字母開頭，駝峰風格，不使用中劃線和下劃線進行區隔，慎用數字；
特殊：下劃線開頭是允許的，表示內部基類；模塊 id 和 元素 id 約定的說明
規則：大寫字母開頭，駝峰風格，不使用中劃線和下劃線進行區隔，慎用數字；
考慮：中劃線使得正則復雜化；駝峰了就自然拒絕下劃線；除非數字有意義，否則慎用數字；base 非常特殊，和 xbase | _parts | partial 分離；
葉子節點示例
imodules/repair/RepairModal/
imodules/repair/RepairModal/
├── main.css
├── main.html
├── main.js
└── screen.tpl
模塊 css 的加載問題
見 jacques_跡遠 的論述 <style>標簽放置位置規范；<style> Tag；style Attribute；模塊的可測試性
建議建立模塊測試機制，實現可單獨調試、可單獨測試、可單獨發布，以支持持續集成、持續測試、持續發布；
ipages（頁面）
ipages
├── home/
│ ├── I404/
│ └── Index/
└── repair/
└── RepairIndex/
- 頁面分類目錄約定；
ipages/home/，ipages/repair/；
命名約定同模塊分類目錄的命名約定； - 頁面實體目錄約定；
BODY id，命名約定同模塊實體目錄的命名約定； - 葉子節點示例
ipages/repair/RepairIndex/
ipages/repair/RepairIndex/
├── images/
│ └── supplier-avatar.png
├── main.css
├── main.js
└── repair@index.html
- repair@index.html，表示發布后 repair/index.html，指定了發布路由；沒有 @ 則表示發布在根目錄下，有幾個 @，則有幾層目錄；有一定的靈活變換性；
iscripts（腳本）
iscripts/
├── immy/
│ ├── libs/
│ ├── baseWidgets.js
│ ├── data.js
│ ├── project.js
│ └── utils.js
├── vendor/
│ └── mustache.js
└── xlibs/
├── common-structure-expanded/
├── global-structure-expanded/
└── tip.js
- mustache.js 放到 vendor 下；
- xlibs 是業務庫，其內容存在相當的不確定性和變動可能；跨業務模塊公用，跨站點公用。這里有一個轉變，就是放到這里的，默認都是全局公用的；
- tip.js 放到 xlibs 下；
immy（基礎框架）
- 基礎框架和應用模塊適度分離，以便進一步重構框架和模塊；
- 新框架命名
使用 immy，簡潔、易記憶，和 Jimmy 有深刻淵源； - immy 框架 可作為產品，以適度分離的方式迭代發展；
immy
├── libs/
│ ├── potato.js
│ └── require.js
├── baseWidgets.js
├── data.js
├── project.js
└── utils.js
immy 應當有繼續演進的機會，雖然 require.js 可以放到 vendor 下，但考慮到若沒有 require.js，這個框架就跑不起來。require.js 屬于 immy 這個框架的最小集合。
idom、ievent、imodule
- 設置 自定義屬性 idom，將 dom 操作從 class 分離；
- 設置 自定義屬性 ievent，明確區分 event 和 action；
- 設置 自定義屬性 imodule，明確引用依賴的模塊 js；
- 基于 els elements 去綁定；
模塊 の 類、函數、變量
- 類名：大寫字母開頭，駝峰風格；
- 變量：小寫字母開頭，駝峰風格；
- 函數：小寫字母開頭，駝峰風格；
- 私有：下劃線開頭表示內部使用；
HTML 元素 の id 和 class
- 元素 id：命名約定同模塊實體目錄的命名約定；
- css class：全小寫，中劃線分隔；
URL、目錄、文件 の 一般命名約定
- URL 設計要盡量簡單、直觀和有意義；
- 除了模塊實體目錄和頁面實體目錄作為 id 使用要加以特殊約定外，目錄文件名統一使用英文小寫（除 README.md 外），慎重使用數字后綴；如果要多個單詞區隔，請使用 中劃線“-”進行區隔；
- CSS 類名也是中劃線區隔，全小寫；
- 網頁鏈接通常使用絕對路徑；
緣起
兩個不同的角色要共享后臺注冊登錄認證服務，但在頁面彈出層有所不同，如何合理復用？
imodules/user/
imodules/user/
├── CustomerLoginForm
├── _LoginForm
└── SupplierLoginForm
約定
后記
- 我們的前兩版結構調整，應該說主要是文件夾的合理組織，工程耦合不是通過文件夾拆分組合（不論多么自洽和復雜）就能簡單解耦的；
- 第三版結構調整，應該說在工程解耦上走出了堅實的一步；
