AMD and CMD are dead之Why Namespace?

缘由

当我看到_Franky兄的微博的时候：

我觉得我有必要出来详细说说KMDjs到底有什么本质上的优势了，连教主_Franky、貘吃馍香都不能理解他的好处，那么可想而知，在前端圈、或是全端圈、或是IT圈，能够理解KMDjs优势的码夫更加是屈指可数。

Why Namespace？

KMDjs是能方便组织Namespace，并且Class Base。针对namespace，我还专门集成可视化库至KMDjs方便查看Namespace Tree。那么Why Namespace?不用会死吗？答案是：不会。但，但是。我要开始念书了（摘自《C#基于工程化的实现与扩展》）：

尴尬的现实状况：

是否有很好的命名空间规划是工程化代码与非工程化代码一个明显的区别。

尤其对于大型的组织而言，如果涉及的产品线、项目、公共平台很多，如何通过命名空间把所有的代码资源有效地组织起来，恐怕是实施项目前腰考虑的主要问题。作为一个树形体系，最好有组织级统一的分类标准，目的很明确----用的时候很容易找到。

无论如果，为了您所带领的团队现在做的工作在以后能更容易地被应用，或者仅仅为你自己的职业生涯好好“储蓄”，在动笔编写第一行程序之前，先规划好命名空间吧。

可参考的建议来自Design Guideline,示例代码如下：

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

例如:Microsoft.WindowPhone.DirectX

一个大型软件企业，总体命名空间的规划如下：

Company.Application

Company.Foundation

Company.Framework

Company.Utility

Company.Training

Application:代表项目或产品

Foundation：代表公共库，类似Enterprise  Library之类的公共基础库、基于企业设备和操作系统平台的通用的图形处理引擎等，但都是纯粹的Class Library，没有UI元素。

Framework：组织通用的框架，基于Foundation之上，面向某个开发领域补充的Class Library和控件，其本身不能独立运行，但完全可以集成在具体的项目或产品中，比如通用的授权框架，完全AJAX化的前后端组建、报表和打印中间件。

Utility:企业内部各种工具，比如现场故障排查工具、Dump和日志分析工具。

Training：完全面向培训用途，是对企业自身Application、Foundation、Framework（甚至Utility）使用的Examples。

当然这是作为C#的空间调用关系，如果仅是web前端的话，应当把CLR部分去掉，如下：

 

不论您最终如果定义命名空间，其实它体现的是您意志中对代码资源的规划。

Who Namespace？

其实早在KMDjs出现之前，google开发团队早就意识到了Namespace的重要性，就弄个类似的东西。不过实现极度蹩脚。那就是老早以前，其代码被喷无数，但依然大名鼎鼎的google-closure-library。比如打开其date.js，可以看到：

provide是暴露的东西，require是依赖的东西。

写那么多不累吗？从上面其实就可以体现Class Base的重要性，但是我会另开一文详细谈下Why Class ？

微软的winjs比google进步了不少，至少意识到了namespace和class的重要性：

 

但winjs还是被kmdjs甩开十条街，因为其没有从工程化的角度考虑问题。

如果你一辈子就切个页面写个焦点图或者打算一辈子切个页面写个焦点图，请无视命名空间，继续require，继续export，继续切页面，写焦点图，继续拿着刚好能糊口的薪水，继续过着买两部iPhone6就月光的日子，庸庸碌碌得打发完一辈子宝贵的时光。

弃暗投明

再给自己一次重生的机会，转生入口：https://github.com/kmdjs/kmdjs