订阅软件研发RSS CSDN首页> 软件研发

深入钻研Augular两年 谈谈其究竟适用于哪些场合

发表于2015-01-30 11:04| 次阅读| 来源www.fse.guru| 0 条评论| 作者Alexey Migutsky

摘要:作为yetu AG全栈工程师,Alexey Migutsky基于对Angular两年的研究经验,表示Angular.js对于大多数项目是“足够好了”,但对于专业的Web应用开发是不够好的。Angular究竟适合与不适合哪些场合,文中做出了详细阐述。

【编者按】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有在什么情况下适合使用?

  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上分享你的实践、方法、问题解决方案,组件和项目结构。

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

原文来自:www.fse.guru   译文来自:伯乐在线

  • CSDN官方微信
  • 扫描二维码,向CSDN吐槽
  • 微信号:CSDNnews
程序员移动端订阅下载

微博关注

相关热门文章