11月中旬在伦敦举行的jQuery Summit顶级大会上有个session讲的是大型JavaScript应用程序架构，看完PPT以后觉得甚是不错，于是整理一下发给大家共勉。

PDF版的PPT下载地址：http://www.slideshare.net/jibyjohnc/jqquerysummit-largescale-javascript-application-architecture

注：在整理的过程中，发现作者有些思想是返来复去地说，所以删减了一部分，如果你的英文良好，请直接阅读英文的PPT。

以下是本文的主要章节：

1. 什么叫“JavaScript大型程序”？

2. 顾当前的程序架构

3. 长远考虑

4. 头脑风暴

5. 建议的架构

?? 5.1 设计模式

??????? 5.1.1 模块论

??????????? 5.1.1.1 综述

??????????? 5.1.1.2 Module模式

??????????? 5.1.1.3 对象自面量

??????????? 5.1.1.4 CommonJS模块

??????? 5.1.2 Facade模式

??????? 5.1.3 Mediator模式

??? 5.2 应用到你的架构

??????? 5.2.1 Facade - 核心抽象

??????? 5.2.2 Mediator - 程序核心

??????? 5.2.3 紧密联合运作起来

6. 发布Pub/订阅Sub的延伸：自动注册事件

7. Q & A

8. 致谢

什么叫“JavaScript大型程序”？

在我们开始之前，我们来定义一下什么叫大型JavaScript站点，很多有经验的JS开发高手也都被challenge住了，有人说超过10万行JavaScript代码才算大型，也有人说JavaScript代码要超过1MB大小才算，其实2者都不能算对，因为不能安装代码量的多少来衡量，很多琐碎的JS代码很容易超过10万行的。

我对“大”的定义如下，虽然可能不太对，但是应该是比较接近了：

我个人认为，大型JavaScript程序应该是非常重要并且融入了很多卓越开发人员努力，对重量级数据进行处理并且展示给浏览器的程序。

回顾当前的程序架构

我不能强调说这个问题有多重要，很多有经验的开发人员经常说：“现有的创意和设计模式在我上一个中型项目上运行得非常好，所以在稍微大型点的程序里再次使用，应该没问题，对吧？”,在一定程序上是没错的，但别忘记了，既然是大型程序，通常就应该有大的Concerns需要分解关注，我简短解释一下要花时间来review当前运行了很久的程序架构。大多数情况下，当前的JavaScript程序架构应该是如下这个样子的（注意，是JS架构，不是大家常说的ASP.NET MVC）：
??? custom widgets
??? models
??? views
??? controllers
??? templates
??? libraries/toolkits
??? an application core.

你可能还会将程序单独封装成多个modules，或者使用其他的设计模式，这很好，但是如果这些结构完全代表你的架构的话，就可能会有一些潜在的问题，我们来看看几个重要的点：

1.你架构里的东西，有多少可以立即拿出来重用？
有没有一些单独的module不依赖别的代码？是自包含么？如果我到你们正在使用的代码库上去随即挑选一些模块module代码，然后放在一个新页面，是否能立即就能使用？你可能会说原理通就可以了，我建议你长久打算一下，如果你的公司之前开发很多重要的程序，突然有一天有人说，这个项目里的聊天模块不错，我们拿出来放在另外一个项目里吧，你能直接拿过来不修改代码就能使用么？

2.系统里有多少模块module需要依赖其他模块？
系统的各个模块是不是都很紧耦合？在我将这个问题作为concern之前，我先解释一下，不是说所有的模块都绝对不能有任何依赖，比如一个细粒度的功能可能是从base功能扩展来的，我的问题和这种情况不一样，我说的是不同功能模块之前的依赖，理论上，所有的不同功能模块都不应该有太多的依赖。

3.如果你程序的某一部分出错了，其他部分是否能够依然工作？
如果你构建一个和Gmail差不多的程序，你可以发现Gmail里很多模块都是动态加载的，比如聊天chat模块，在初始化页面的时候是不加载的，而且就算加载以后出错了，页面的其他部分也能正常使用。

4.你的各个模块Module能很简单的进行测试么？
你的每一个模块都有可能用在数百万用户的大型站点上，甚至多个站点都使用它，所以你的模块需要能经得住测试，也就是说，不管是在架构内部还是架构外部，都应该能很简单的去测试，包括大部分的断言在不同的环境下都能够通过。

长远考虑

架构大型程序的时候，最重要的是要有前瞻性，不能只考虑一个月或者一年以后的情况，要考虑更长久的情况下，有什么改变的可能性？开发人员经常将DOM操作的代码和程序绑定得太紧，尽管有时候已经封装单独的逻辑到不同的模块里了，想想一下，长久以后，为什么不是很好。

我的一个同事曾经说过，一个精确的架构可能不适合未来的情景，有时候是正确的，但是当你需要该做的话，你所付出的money那可是相当地多哦。比如，你可能因为某些性能，安全，设计的原因需要在Dojo, jQuery, Zepto, YUI之间需要选择替换，这时候就有问题了，大部分模块都有依赖，需要钱呀，需要时间啊，需要人呀，对不？

对于一些小型站点没事，但是大型站点确实需要提供一个更加灵活的机制，而不去担心各个模块之间的各种问题，这既然节约钱，又能节约时间。

总结一下，现在你能确定你能不重写整个程序就能替换一些类库么？如果不能，那估计我们下面要讲的内容，就比较适合你了。

很多有经验的JavaScript开发者给出了一些关键的note