緣由

當我看到_Franky兄的微博的時候：

我覺得我有必要出來詳細說說KMDjs到底有什么本質(zhì)上的優(yōu)勢了，連教主_Franky、貘吃饃香都不能理解他的好處，那么可想而知，在前端圈、或是全端圈、或是IT圈，能夠理解KMDjs優(yōu)勢的碼夫更加是屈指可數(shù)。

Why Namespace？

KMDjs是能方便組織Namespace，并且Class Base。針對namespace，我還專門集成可視化庫至KMDjs方便查看Namespace Tree。那么Why Namespace?不用會死嗎？答案是：不會。但，但是。我要開始念書了（摘自《C#基于工程化的實現(xiàn)與擴展》）：

尷尬的現(xiàn)實狀況：

是否有很好的命名空間規(guī)劃是工程化代碼與非工程化代碼一個明顯的區(qū)別。

尤其對于大型的組織而言，如果涉及的產(chǎn)品線、項目、公共平臺很多，如何通過命名空間把所有的代碼資源有效地組織起來，恐怕是實施項目前腰考慮的主要問題。作為一個樹形體系，最好有組織級統(tǒng)一的分類標準，目的很明確----用的時候很容易找到。

無論如果，為了您所帶領(lǐng)的團隊現(xiàn)在做的工作在以后能更容易地被應(yīng)用，或者僅僅為你自己的職業(yè)生涯好好“儲蓄”，在動筆編寫第一行程序之前，先規(guī)劃好命名空間吧。

可參考的建議來自Design Guideline,示例代碼如下：

<Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace>]

例如:Microsoft.WindowPhone.DirectX

一個大型軟件企業(yè)，總體命名空間的規(guī)劃如下：

Company.Application

Company.Foundation

Company.Framework

Company.Utility

Company.Training

Application:代表項目或產(chǎn)品

Foundation：代表公共庫，類似Enterprise  Library之類的公共基礎(chǔ)庫、基于企業(yè)設(shè)備和操作系統(tǒng)平臺的通用的圖形處理引擎等，但都是純粹的Class Library，沒有UI元素。

Framework：組織通用的框架，基于Foundation之上，面向某個開發(fā)領(lǐng)域補充的Class Library和控件，其本身不能獨立運行，但完全可以集成在具體的項目或產(chǎn)品中，比如通用的授權(quán)框架，完全AJAX化的前后端組建、報表和打印中間件。

Utility:企業(yè)內(nèi)部各種工具，比如現(xiàn)場故障排查工具、Dump和日志分析工具。

Training：完全面向培訓(xùn)用途，是對企業(yè)自身Application、Foundation、Framework（甚至Utility）使用的Examples。

當然這是作為C#的空間調(diào)用關(guān)系，如果僅是web前端的話，應(yīng)當把CLR部分去掉，如下：

不論您最終如果定義命名空間，其實它體現(xiàn)的是您意志中對代碼資源的規(guī)劃。

Who Namespace？

其實早在KMDjs出現(xiàn)之前，google開發(fā)團隊早就意識到了Namespace的重要性，就弄個類似的東西。不過實現(xiàn)極度蹩腳。那就是老早以前，其代碼被噴無數(shù)，但依然大名鼎鼎的google-closure-library。比如打開其date.js，可以看到：

provide是暴露的東西，require是依賴的東西。

寫那么多不累嗎？從上面其實就可以體現(xiàn)Class Base的重要性，但是我會另開一文詳細談下Why Class ？

微軟的winjs比google進步了不少，至少意識到了namespace和class的重要性：

但winjs還是被kmdjs甩開十條街，因為其沒有從工程化的角度考慮問題。

如果你一輩子就切個頁面寫個焦點圖或者打算一輩子切個頁面寫個焦點圖，請無視命名空間，繼續(xù)require，繼續(xù)export，繼續(xù)切頁面，寫焦點圖，繼續(xù)拿著剛好能糊口的薪水，繼續(xù)過著買兩部iPhone6就月光的日子，庸庸碌碌得打發(fā)完一輩子寶貴的時光。

棄暗投明

再給自己一次重生的機會，轉(zhuǎn)生入口：https://github.com/kmdjs/kmdjs