但看到不少人感觉用Angular不好招人，不好组建团队，我想分享一下我的相关经验。
我自己对Angular熟悉，程序架构是我负责，比如让程序跑起来、模块的划分和基础工具的编写。然后整个程序的编写不只我一个人，因为老板怕我累着——我说的是真的，因为去年在开发子公司关乎“生死存亡”的项目时，老板依然足额放了我们的清明假。
既然程序不只我一个人写，当然就要组建团队。而项目又急，临时招人又有点不太现实。因此团队成员只能从兄弟子公司和总公司借，而借来的小伙伴中没有一个是会Angular的——最多只是听过AngularJS很火（过）。
尽管如此，公司存活下来了，因为项目如期按质完成——它还上了省台新闻。
而在项目开发的初期，借来的小伙伴们根本没有意识到（当然，他们知道）自己在开发“Angular应用程序”，他们只在创建一个个被叫做“服务”的TypeScript类，然后在里面写处理Web API交互和业务逻辑的代码——这些代码和他们在“jQuery时代”已经写“吐”了的JavaScript代码太像了，不同的是，他们在当时以及随后的整个开发过程中没有写任何一行操作DOM的代码。
没过两天小伙伴们开始创建一个个叫“组件”的TypeScript类，然后在里面写处理用户交互以及和前面的服务交互的代码——这些代码仍然基本上可以认为就是JavaScript代码，但包含简单的一些Angular元素，比如路由参数和导航。
又没过两天，小伙伴们开始创建HTML和CSS文件，并编写相应的代码——这些代码仍然没什么变化，除了多了NgIf和NgFor等几个常用的指令。
就这样，我写和Angular紧密相关的代码（当然还有不紧密相关的），零Angular基础（但有“jQuery时代”的Web开发经验）的小伙伴们写和Angular无关的业务逻辑代码以及和Angular不太相关的应用逻辑代码和UI代码，四十天之后我们便相对轻松地“救公司于水火”，而老板也给我们发了几千块钱的奖金——总公司来的小伙伴发的是绩效评分。。
所以从我的经验来看，如果公司里有一个熟悉Angular的人，那么在很多（我猜的，我不知道多少）情况下根本不需要招第二个会Angular的人（当然能招到更好），只需要招两种（第一种是不可或缺的）小伙伴就好了：
1，有Web前端开发经验，熟悉HTML和CSS，会JavaScript——根据小伙伴各技能的熟练程度来决定给他/她写业务/应用逻辑或UI代码；
2，有面向对象开发经验（不管是服务端、移动端、桌面或其它平台），熟悉JavaScript并可快速掌握TypeScript——显然，他们更适合写业务逻辑代码和应用逻辑代码。
事情真的就是这么简单，因为Angular帮我们做好了职责分离（当然，第一个做这件事情的不是Angular）。一个人独自开发基于Angular的应用程序，这个人确实需要了解Angular的方方面面；但一个人参与基于Angular的应用程序开发，这个人甚至根本不需要了解Angular，或只需简单地了解Angular中的几个指令和路由API，以及一些规范。
其实好的框架都是这样的：隐藏底层平台和框架本身的技术细节，让开发人员用最简单的方式实现所需的功能——当然，知道这些细节能开拓我们的技术视野。
好了，总结一下：在我看来，如果公司里有熟悉Angular的小伙伴，那么招开发Angular应用程序的小伙伴不难，因为我们根本不需要他们会Angular。
或许有人会说：如果公司里没有熟悉Angular的小伙伴怎么办？
我可能不知道，但我可以说我熟悉吗。。
或许还有人会说：现在熟悉Angular的人不多（是不是这样我真不知道），如果公司里会Angular的（那个）小伙伴走了怎么办？
这个我知道，其他愿意来参与Angular应用程序开发的小伙伴多少都是对Angular感兴趣的，在一个好的环境下他们要不了多少时间就能熟悉Angular的方方面面，毕竟Angular真不难学，官方文档还这么全。
最后，如果有人对Angular感兴趣或充满疑惑（比如它是否真的像传言那样学习曲线陡峭或不适合小型应用程序开发），不妨看看我写的《Angular应用程序开发指南》，我将试着带读者不知不觉地走进Angular的世界。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。