【编者按】Alexey Migutsky，yetu AG全栈工程师，Web前端技术专家。近日他发表文章《2 years with Angular》分享了他近两年钻研Angular所获得的成果，包括Angular适合及不适合哪些场合，Angular的优缺点及框架开发者所应吸取的经验教训。伯乐在线对该外文进行了翻译，译文如下：

Angular到底是什么啊？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

团队的经验不同；

需要不断发展的项目；

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

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

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

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

使用Angular做原型没问题，轻松搞定；

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

坐下来分析你犯的设计错误；

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

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

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

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

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

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

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

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

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

Angular不好的部分

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

糟糕的抽象；

糟糕的性能；

名称冲突；

复杂性；

第三方模块；

没有可供参考的经验代码。

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

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

是的那些问题可以避免。

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

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

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

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

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

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

你学到什么了吗？

对于有经验的开发者来说一些问题开始就已经很明显了。只是这些点子都很棒啊，团队也认为没问题，就觉得应该不会出错吧。

我相信那些问题将会被逐步解决。Github上有很多有价值的讨论。有很多pull请求。有很多可以解决问题的方法。但事实是：这些解决方法还在讨论中，并没有被合并进去。

一些问题在Angular 1.*中永远都不能被解决。

我相信我可以教人们把事做对。但是没有框架的支持就必须一遍又一遍的解释。

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

必须尽可能少的使用抽象。

命名必须和你的“思维领域”一致。

不要混淆组件的功能。用明确定义的角色进行细粒度的抽象。

在文档中描述你这些决定的目的，以及你所做的权衡妥协。

写一个完善并且保持更新的参考项目或例子。

抽象必须是“自底向上”的，从一些小项目开始，逐渐组成复杂的模式。不要一开始就问“我们应该如何全局的重载？”

全局状态是恶魔。它就像恐怖电影里的黑暗一样。你永远不知道踏进去会有什么问题发生。

数据流和数据变化应该是粒度化的，而且定位到单独的组件。

不要让事情易于使用，让你的组件和抽象简单，易于理解。人们应该学会新的有效的方式，不要适应他们的舒适区域。

把所有你知道的好东西都编码到框架里。制作“导轨”，如果有不正确的操作，就抛出警告。

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

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

但我用Angular工作很开心！

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

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