1. 不要先设计页面，然后再使用DOM操作来改变它的展现

在jQuery中，你通常会设计一个页面，然后再给它动态效果。这是因为jQuery的设计就是为了扩充DOM并在这个简单的前提下疯狂的生长的。

但是在AngularJS里，必须从头开始就在头脑中思考架构。必须从你想要完成的功能开始，然后设计应用程序，最后来设计视图，而非“我有这么一个DOM片段，我想让他可以实现XXX效果”。

2. 不要用AngularJS来加强jQuery

类似的，不要以这样的思维开始：用jQuery来做X，Y和Z，然后只需要把AngularJS的models和controllers加在这上面。这在刚开始的时候显得非常诱人，这也是为什么我总是建议AngularJS的新手完全不使用jQuery，至少不要在习惯使用“Angular Way”开发之前这么做。

我在邮件列表里看到很多开发者使用150或200行代码的jQuery插件创造出这些复杂的解决方案，然后使用一堆callback函数以及$apply把它粘合到AngularJS里，看起来复杂难懂；但是他们最终还是把它搞定了！问题是在大多数情况下这些jQuery插件可以使用很少的AngularJS代码重写，而且所有的一切都很简单直接容易理解。

这里的底线是：当你选择解决方案时，首先“think in AngularJS”；如果想不出一个解决方案，去社区求助；如果还是没有简单的解决方案，再考虑使用jQuery。但是不要让jQuery成为你的拐杖，导致你永远无法真正掌握AngularJS。

3. 总是以架构的角度思考

首先要知道Single-page应用是应用，不是网页。所以我们除了像一个客户端开发者般思考外，还需要像一个服务器端开发者一样思考。我们必须考虑如何把我们的应用分割成独立的，可扩展且可测试的组件。

那么如何做到呢？如何“think in AngularJS”？这里有一些基本原则，对比jQuery。

视图是“Official Record”

在jQuery里，我们编程改变视图。我们会将一个下拉菜单定义为一个ul ：

<ul class="main-menu">
    <li class="active"> <a href="#/home">Home</a> </li>
    <li> <a href="#/menu1">Menu 1</a> 
        <ul>
            <li><a href="#/sm1">Submenu 1</a></li> 
            <li><a href="#/sm2">Submenu 2</a></li>
            <li><a href="#/sm3">Submenu 3</a></li>
        </ul>
    </li>
    <li> <a href="#/home">Menu 2</a> </li>
</ul>

在jQuery里，我们会在应用逻辑里这样启用这个下拉菜单：

$('.main-menu').dropdownMenu();

当我们只关注视图，这里不会立即明显的体现出任何（业务）功能。对于小型应用，这没什么不妥。但是在规模较大的应用中，事情就会变得难以理解且难以维护。

而在AngularJS里，视图是基于视图的功能。ul声明就会像这样：

<ul class="main-menu" dropdown-menu> ... </ul>