作者当然也不容易，要考虑各种兼容问题，要考虑效率问题（他真的考虑过吗，我表示强烈怀疑，貌似仅仅是风格上模仿其他源码）
相当无语。
本来我是知道的，代码 调试的过程中逐渐完善，逐渐与各种兼容问题和预想不到的bug打交道，原先严谨的结构都会渐渐腐烂，但是作者的结构，真的不是很严谨。
因为有些设计，完全是为兼容性而来的，所以有些即使没有理解，我也不去理解了，毕竟，我没有打算去维护这套代码。
我还是就这套代码的利弊进行一下总结吧。
1.命名一定要有意义，如果是临时起的无意义的名字，那么后期重构的时候要改成有意义的。有些如checkdeps,这是什么意思，有些代码基本上是为了解决兼容性问题的，起名字的时候，就不能按照代码内容来起，因为读者并不知道你所熟知的那些兼容性问题。有时候定义了若干重名的变量，比如id=xxx?id:yyyy之类的，然后又用url 作为复杂ID，又如闭包内外变量重名，造成了后来维护者的极大混淆。
如果你指望别人来维护这段代码，请不要出现ID,LIST,ARRAY这样的变量，哪怕是作为临时变量也不行。光看一个函数还可以，看多几个乱得一塌糊涂。
命名应根据功能，作用来命名，而不应根据细节来命名。
2.跟命名一致的，代码功能问题。 全局变量的使用，可能在所难免，但请务必一点，把兼容和非兼容的代码分开。正常代码考虑兼容问题，几乎必然会违背单一职责原则的。兼容代码里尤其会有各种拼凑写法，巧合写法，这些最好和正常的逻辑处理分开，尤其是复杂的逻辑。应设法使逻辑和兼容分离，逻辑独自封装一块。
数据结构的设计尤其不应考虑兼容问题。 否则你的框架就跟某个版本的浏览器高度相干了，后人想改都改不过来。代码的复杂是有序的，有限度的，兼容性的复杂是无穷无尽的，无规律的。没必要做什么url命名，多个不同版本报错问题，现在明摆着，你一个版本都还没做出来，那些使种子模块过早的陷入一种想象出来的复杂需求之中。
两个不同版本的模块加载，得不到正确结果，这是必然的，无法根除的。
你的代码要跟jquery拼效率那是不可能的事情，如果要后人还能维护，请一定不要跨若干个层级的函数调用全局变量。
有节制的使用全局变量和闭包，使用前一定要考虑好，为什么在这个位置要用，有什么好处，最大的好处莫过于可以封装一整块功能。
复杂结构最好一次性定义完，不要在程序流行过程中断断续续的添加。