遵循良好的OO设计原则和设计模式有助于使代码易于维护和理解。 但我最近发现的最好的东西之一是信号和槽，也就是发布/订阅。 看看http://markdotmeyer.blogspot.com/2008/09/jquery-publish-subscribe.html 简单的jQuery实现。

这个想法在其他语言的GUI开发中也得到了很好的应用。当代码中某个重要的事件发生时，你会发布一个全局合成事件，其他对象中的其他方法可能会订阅该事件。 这提供了很好的对象分离。

我认为Dojo(和Prototype?)有这种技术的内置版本。

参见什么是信号和槽?

如果javascript内置了名称空间，那就更好了，但我发现像Dustin Diaz在这里描述的那样组织东西对我有很大帮助。

var DED = (function() {

    var private_var;

    function private_method()
    {
        // do stuff here
    }

    return {
        method_1 : function()
            {
                // do stuff here
            },
        method_2 : function()
            {
                // do stuff here
            }
    };
})();

我把不同的“名称空间”放在不同的文件中，有时把单独的类放在不同的文件中。通常我从一个文件开始，当类或名称空间变得足够大时，我将它分离到自己的文件中。使用工具将所有文件组合起来进行生产也是一个很好的主意。

"Write like crazy and just hope it works out for the best?", I've seen a project like this which was developed and maintained by just 2 developers, a huge application with lots of javascript code. On top of that there were different shortcuts for every possible jquery function you can think of. I suggested they organize the code as plugins, as that is the jquery equivalent of class, module, namespace... and the whole universe. But things got much worse, now they started writing plugins replacing every combination of 3 lines of code used in the project. Personaly I think jQuery is the devil and it shouldn't be used on projects with lots of javascript because it encourages you to be lazy and not think of organizing code in any way. I'd rather read 100 lines of javascript than one line with 40 chained jQuery functions (I'm not kidding). Contrary to popular belief it's very easy to organize javascript code in equivalents to namespaces and classes. That's what YUI and Dojo do. You can easily roll your own if you like. I find YUI's approach much better and efficient. But you usualy need a nice editor with support for snippets to compensate for YUI naming conventions if you want to write anything useful.

我认为这可能与DDD(领域驱动设计)有关。我正在开发的应用程序，虽然缺乏正式的API，但确实通过服务器端代码(类/文件名等)给出了提示。有了这些，我创建了一个顶级对象作为整个问题域的容器;然后，我在需要的地方添加名称空间:

var App;
(function()
{
    App = new Domain( 'test' );

    function Domain( id )
    {
        this.id = id;
        this.echo = function echo( s )
        {
            alert( s );
        }
        return this;
    }
})();

// separate file
(function(Domain)
{
    Domain.Console = new Console();

    function Console()
    {
        this.Log = function Log( s )
        {
            console.log( s );
        }
        return this;
    }
})(App);

// implementation
App.Console.Log('foo');

我的老板仍然在谈论他们编写模块化代码(C语言)的时代，并抱怨现在的代码是多么糟糕!据说程序员可以在任何框架中编写程序集。总有一种策略可以克服代码组织。最基本的问题是那些把java脚本当作玩具的人，从来没有尝试去学习它。

在我的例子中，我在UI主题或应用程序屏幕的基础上编写js文件，使用适当的init_screen()。使用适当的id命名约定，我确保在根元素级别上没有名称空间冲突。在不引人注目的window.load()中，我根据顶级id将内容绑定起来。

我严格使用java脚本闭包和模式来隐藏所有私有方法。这样做之后，再也没有遇到属性/函数定义/变量定义冲突的问题。然而，当与团队一起工作时，通常很难执行同样的严格性。

创建假类，并确保任何可以被扔进单独函数的有意义的东西都被这样做了。还要确保大量注释，而不是编写面条式的代码，而是将代码分块编写。例如，一些无意义的代码描述了我的理想。显然，在现实生活中，我也编写了许多包含它们功能的库。

$(function(){
    //Preload header images
    $('a.rollover').preload();

    //Create new datagrid
    var dGrid = datagrid.init({width: 5, url: 'datalist.txt', style: 'aero'});
});

var datagrid = {
    init: function(w, url, style){
        //Rendering code goes here for style / width
        //code etc

        //Fetch data in
        $.get(url, {}, function(data){
            data = data.split('\n');
            for(var i=0; i < data.length; i++){
                //fetching data
            }
        })
    },
    refresh: function(deep){
        //more functions etc.
    }
};