那到底是什么啊？

我用两年时间深入钻研Angular。

我接触过十几个基于Angular的项目，接触到不同的团队和思想。

第一年我看到框架被采用，API的改变，文档的改进和社区的形成，从上到下的了解了Angular。

另一年是完全的亲手实践，提供咨询。

我的结论是：Angular.js对于大多数项目是“足够好了”，但是对于专业的Web应用开发是不够好的。

你所谓的“专业Web应用”是指什么?

我所说的“专业Web应用”指的是长久可维护，在所有的现代浏览器中都表现良好，有着流畅的用户体验，且对移动设备友好的Web应用。

专业的Web应用不是简单的只解决特定问题的工件，它是可以让用户愉快使用的产品.

这个应用应该完成的相当快，采用各种最佳实践，不仅在代码层面（优秀的设计、简单的概念、容易掌握的组件)，而且还包括部署过程（CDN、代码压缩、搜索引擎优化、关键路径优化等)，以及可用性领域（加载速度、内容优先、故障弱化，信息组织，等等 )。

Angular有在什么情况下适合使用？

1. 构建基于表单的“CRUD（创建、查询、删除、更新）应用”。

2. 临时的项目（例如原型系统，小应用程序）。

3. 行动迟缓的大企业，当性能无关紧要，而且不用考虑维护的开销。（但是你试过ExtJS吗？）

什么情况下Angular绝对不适合呢？

1. 团队的经验不同。

2. 需要不断发展的项目。

3. 缺少资深的前端开发主管来经常浏览代码。

4. 有着五星级性能需求的项目。

当然，这些问题可能所有的框架和项目都有。但是Angular会比其他MVC框架更快带来更严重的问题。

如果被迫要使用Angular，有什么好用的策略呢？

1. 使用Angular做原型没问题，轻松搞定。

2. 一旦原型被证明是要做的事情，那么马上忘掉原型，不要继续发展它。

3. 坐下来分析你犯的设计错误。

4. 开始一个新的项目，最好用其他的技术堆栈。

5. 把原型的功能导入到MVP（最简化可实行产品）中。

如果你仍然需要发展你的项目并且在未来维护它：

1. 接受你将在未来承受痛苦的现实吧，降低期望有时候会让你开心一些。

2. 用这些流行的AngularJS风格指导 (这个, 这个 和 这个)建立一个完整的指南，能够覆盖到所有你能想到的用例和模式.

3. 用你OOD（基于对象设计）的知识尝试保持一切尽可能的松耦合。

4. 使用MVC或者MVVM，但不要把它们混起来用的。

5. 把“重构”的迭代放到开发过程中（最好每三个月一次）

6. 建立一个基于Angular的元框架，针对你项目的需求和你团队的经验进行裁剪。

Angular不好的部分

如果你还在读，我建议你深入了解一些主要的问题，写在下面的博客中：

1. 糟糕的抽象

2. 糟糕的性能

3. 名称冲突

4. 复杂性

5. 第三方模块

6. 没有可供参考的经验代码

“不，Angular很酷！你只是不知道Angular怎么做事！”

很久以来我都这样告诉别人，试图证明我是错的。

是的那些问题可以避免。

但是你必须花大量的时间来学习框架的细节。

你要在开发过程中引入那些“警告标志”。

你必须花时间来绕过那些问题。

嘿，你会解决这些框架强加给你的问题。

但这不是你试图实现高性能的专业应用时想要做的事情。

而且“变通的方法”也不是你想要维护的东西。

你学到什么了吗？

1. 对于有经验的开发者来说一些问题开始就已经很明显了。只是这些点子都很棒啊，团队也认为没问题，就觉得应该不会出错吧。
2. 我相信那些问题将会被逐步解决。
   Github上有很多有价值的讨论。有很多pull请求。有很多可以解决问题的方法。
   但事实是：这些解决方法还在讨论中，并没有被合并进去。
3. 一些问题在Angular 1.*中永远都不能被解决。
4. 我相信我可以教人们把事做对。但是没有框架的支持就必须一遍又一遍的解释。

框架（元框架）开发者的经验教训：

1. 必须尽可能少的使用抽象。
2. 命名必须和你的“思维领域”一致。
3. 不要混淆组件的功能。用明确定义的角色进行细粒度的抽象。
4. 在文档中描述你这些决定的目的，以及你所做的权衡妥协。
5. 写一个完善并且保持更新的参考项目或例子。
6. 抽象必须是“自底向上”的，从一些小项目开始，逐渐组成复杂的模式。不要一开始就问“我们应该如何全局的重载？”
7. 全局状态是恶魔。它就像恐怖电影里的黑暗一样。你永远不知道踏进去会有什么问题发生。
8. 数据流和数据变化应该是粒度化的，而且定位到单独的组件。
9. 不要让事情易于使用，让你的组件和抽象简单，易于理解。人们应该学会新的有效的方式，不要适应他们的舒适区域。
10. 把所有你知道的好东西都编码到框架里。制作“导轨”，如果有不正确的操作，就抛出警告。

嘿，我需要一些其他的选择！不要只给我这些！这不公平！

好吧，不好意思还没搞定它们，但你可以点击这里!

但我用Angular工作很开心！

如果真是喜欢的话，请你在github上分享你的实践、方法、问题解决方案，组件和项目结构。

但如果不是真喜欢这些东西的话，就不要勉强做。

Alexey Migutsky，全栈工程师。我用魔法让 IT 工作。