Car2go 的前端框架选择

作者：Sumit Kumar 原文链接：car2godevs

2016年12月，car2go 开始在柏林及汉堡组建新的前端团队开发一些内部产品。汇聚了一批有 NodeJS、前端、rails 以及其它开发经验的人，很快，前端框架的问题暴露出来了。

在2017年组建一支新的前端开发团队意味着不得不面对框架选择的争论。虽然我已经是一些框架的粉丝了，但我还是给团队机会来解决这个问题，我希望接下来的两年都不再起争论。在本文中，我会讲讲我们是怎么做的以及我们最后的选择。

问题

将拥有不同经验、背景、编程思维和技能的人聚到一个团队里，意味着他们每一个人对理想的产品、工作流和编码风格都有不同的想法。水平层次高低也意味着部分开发者选择某一框架纯粹是出于偏爱或者之前的项目中用过。而另一部分开发者则会关注商业应用以及 App 需求。我的角色是找到一个可长期使用的、社区活跃的、已熟悉的以及开发者们愿意使用的框架。

有一点很重要，这个决定不由某一个管理者做出，而是开发团队中的一些产品所有者和我一起讨论。并且我还加了一些更高的要求：比如新人上手的时间。

这一想法的目的是缩小满足需求的框架的范围，让开发者们能在一个「hackweek」内用这些框架做一些小的 App。接着，他们会围绕这些 App 进行讨论，共同客观的决定一个框架。

这项工作不能盲目的进行，所以我们定了一些规则。

Hackweek 规则

每一个开发者都独立的从头开发产品
必须选一个自己不喜欢或不熟悉的框架。这能降低认知偏差，同时能让他们更客观的评价所使用的框架。
所开发的产品必须能让他们深入的了解框架。不能是一个简单的 to-do demo。
所有人都开发同一个产品（后面会讲）以更好的比较结果。
每个人在 hackweek 期间都必须按预设的规则来开发产品

候选框架及标准

有些框架马上就能做出决定。比如 backbone、ember 和 angular1，都2017年了还选它们没有意义。比较明显的社区活跃且有前景的三个框架是 reactJS,angular2 和 vueJS。 VueJS 知道的人较少，而 React 和 Angular 业界及团队已经有许多讨论了。在用其中某个框架做开发的时候，开发人员需要总结经验。

至于别的框架，需要考虑的标准有：

文档
维护者的活跃度
常用平台上的提问和回答
可用工具
插件或扩展的数量及质量
Web 技术标准
设置开发环境所需时间（设置开发和支持工具，比如 sass ,自定义字体等）
代码风格，API 设计
可拓展性

需要开发的产品

要开发的产品很直观：在单张地图上显示所有 Car2go 的车辆（不使用任何已有的单张地图框架），数据每10s 更新一次。每一座城市/地点都能够通过 URL 及选框选中。

获取车辆的地理位置信息并显示在地图上。然后计算每一区域的车辆总数显示在该区域中——每10s 更新一次。

开发者们需要确定路由、状态管理、HTTP 请求的解决方案。并且为了应用单张地图，即使不在框架更新机制中的 DOM 也需要响应状态变化。这对于开发者探索组件的生命周期与响应等细节非常有帮助。

汇报日

某一个周五，整整一天都被用来展示作品以及进行后续讨论。每一个开发者都展示了自己的进展，讲了框架的难点和好处。在网上获得帮助/答案是否容易？文档是否完善？回答问题，渐渐开始小范围讨论，解释该框架执行我们标准的方式。比如用过 Angular 2 的开发者看了首次使用的人的汇报后，可以回应他们遇到的问题，而汇报的人也能了解到另一种解决问题的办法。

有一些人在初次尝试之后就对其所使用的框架表现出极大的热情。有一些人简单的说他们用的框架不错、用它来做开发没问题。还有一部分人对自己使用的框架感到失望，不推荐使用该框架。

最后，团队共同客观的决定一个用起来舒服的框架作为最终选择。

我们的选择及一些有趣的评价

我想分享下汇报日中产生的一些有趣的争论。注意这不是要罗列各框架的优劣点。

一些人建议不要用 VueJS ,因为 StackOverflow 上没有足够多相关的问题。而另一些人认为这恰恰说明 Vue 的文档完备且 Vue 论坛活跃。当然，到目前为止，VueJS 的文档的确是最完善的。

TypeScript 也引起了较大的争议。最终，团队决定采用标准 ES6 以免给后续接手我们 app 的开发团队留下太多坑。毕竟，我们所有人都不想接手一个 CoffeeScript App。但以防万一，我们用 Flow 做类型检查。

至于 Angular 2，尽管在使用 TypeScript 时， Angular 2 有一些好用的工具，但是「hackweek」中，它没有获得新的支持者。它的文档，尤其是 JavaScript 文档，不完善、冗长且令人迷惑。开发者们需要更多的时间来上手和使用它。而且它诡异的发布周期让人对其未来没有任何信心。这时候第4版(!)都发布了。

JSX vs Directives - HTML in JS vs Logic in HTML 也是一个有趣的争论点。最后，团队得出结论： directive 让 HTML 更具可读性，并且大家有使用 Angular 1 的经验，所以对 directive 更熟悉。VueJS 虽然支持了 JSX 但是它对 directive 的处理也非常优雅。

ReactJS 和 VueJS 彼此类似，但是在文档和 API 的优雅程度上，VueJS 更胜一筹。

最后说一下，所有的框架都解决了我们的问题，而且所有开发者都有所偏爱。所以不要直接采用我们的决策或者将其作为一个放之四海而皆准的事实。而是将它看作是我们的开发者比较赞同的意见。

未来

frontend landscape 每隔一周介绍一款新的框架(hello,moonJS),开发者们显然想试试这些框架。在可预见的未来，我们会用 VueJS 开发和主体业务有关的 app，而在一些概念验证性产品及仪表盘 app 中会使用新出现的框架。

总结

从参与「hackweek」的开发者、管理人员和其它观察者的反馈来看，这一周对我来说相当成功，虽然开销有点贵（这一周啥也没开发）。但没让团队走上另一条道路（技术问题），也打开了更轻松的进行团队合作的大门。如同移交 app 给其它团队，分享知识的最佳办法：通用组件。

翻译：YoungZ 部分翻译采用意义；水平有限，翻译中可能有微小错误（但不影响掌握文章大意）请指出。