怎么选框架？
这个命题看似是技术leader做的事情，实际上作为前端开发人员不得不面临这样的事实。公司的选择决定了你的技术走向。
首先，选择一款框架，实质是在选择一种工具，选择*合适*的工具。工欲善其事必先利其器，工具都没有选择好，谈不上什么美好的结果。
其次,每个人的选择是根据他自身的，一个公司团队的选择是根据业务自身和团队自身的。无非是在现有的条件之下，做出符合他自身往前发展的选择。选择开始都是一张白纸，考虑的因素列成了清单，一项一项比较权重，最后得到一个加权平均数的结果。
我们团队是如何选择？
* 我们没有测试人员。我们公司做的大多是国际互联网国际业务，开发的产品都是服务这个业务。在前端展示交互方面相对于来说要求比较低，因为主要的业务靠的是底层算法来实现。而使用我们开发的产品是公司内部人员和一些开发者。在前端方面，都是自己测试上线。这不得不让我们团队考虑，一款“整齐”的框架。ember自带了测试的CLI，相对于其他框架需要引入测试的插件，方便很多。更重要的是，这项测试的成本相对比较低。
* 前端太过依赖后端提供接口再干活。广告行业的开发人员流动频繁，每个新入职的员工，或者其他项目转过来的同事，如果要马上进入项目，后台接口变成了阻碍进度的理由。ember的mirage模拟API接口的方案，解决了这样的锚段。
* 前端团队组建后，代码的风格各有特点，codestyle，gulpfile,文件命名，项目结构都是五花八门。往往第一代产品做出来之后，维护人员，感觉代码很难维护，甚至看不懂。然后再次提重构方案。ember整个框架都遵循约定大于设置的哲学，代码风格十分规范。全部组件开发之后，项目结构清晰。
* 后端的API规范。我们公司也迫切需要对接口的格式进行规范。而ember默认的JSONAPI就是后端约定规范的最佳实践。实际开发中，感觉到ember这些约定规范的束手束脚。而恰恰是这些类似‘成年仪式’的考验和束缚，让整个团队的代码质量得到提升。
我们是如何切入ember开发的？
1. 搜集反馈。
在选择框架上，领导会表现两种态度，一是直接拍脑袋说上，二是你们自己选，反正不耽误项目进度就行。
我们团队属于前者，但是这这个选择之前，安排了一周时间进行学习框架知识。一周之后汇总所有人的反馈。没有人用过ember，通过反馈的结果，结合我们选择的时候考虑的因素，我们团队最后决定选择ember。
2. 沟通。
ember-data是学习过程中遇到最大的问题，有成员直接放弃，我们采取主动沟通。告知领英、Sony、Apple、Netfix等都在使用ember进行开发。对遇到的问题，再细致的研究，分享成果和方案。让后端人员也参与讨论，
后端提供标准的JSONAPI格式。
3. 边试边改错。
随着项目的推进，我们一点一点用ember，用了起来。ember的学习曲线陡峭，主动分解出来学习曲线的周期，告知团队成员，另外振奋士气也是一项比较基础的产能开发。
总结
作为开发人员，我们需要了解为什么选择这种框架。因为问题不在于选择的是什么框架让你提升开发能力，而在于你在开发过程中吸收了什么思想和经验。几大前端框架比较下来，其实都是异曲同工的。而ember强调的是数据规范，更有利于自身的代码修养。
