avaScrip架构模式.docxVIP

窗体底端大型JavaScript应用程序架构模式 2011-12-14 21:13:50 ??11月中旬在伦敦举行的jQuery Summit顶级大会上有个session讲的是大型JavaScript应用程序架构，看完PPT以后觉得甚是不错，于是整理一下发给大家共勉。PDF版的PPT下载地址：/jibyjohnc/jqquerysummit-largescale-javascript-application-architecture注：在整理的过程中，发现作者有些思想是返来复去地说，所以删减了一部分，如果你的英文良好，请直接阅读英文的PPT。什么叫“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之间需要选择替换，这时候就有问题了，大部分模块都有依赖，需要钱呀，需要时间啊，需要人呀，对不？对于一些小型站点没事，但是大型站点确实需要提供一个更加灵活的机制，而不去担心各个模块之间的各种问题，这既然节约钱，又能节约时间。总结一下，现在你能确定你能不重写整个程序就能替换一些类库么？如果不能，那估计我们下面要讲的内容