与Angular一起的两年

那到底是什么啊?

我用两年时间深入钻研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 工作。

2 收藏 评论

关于作者:冲哥Bob

80后 吉尼赛斯Genesys(年老的)软件工程师 甜甜爸爸 一直在减肥的胖子(新浪微博:@冲哥Bob) 个人主页 · 我的文章 · 10

相关文章

可能感兴趣的话题



直接登录
跳到底部
返回顶部