面向专业开发者的 Meteor

昨天是小白开发者,今天说说 Meteor 如何面向专业开发者。

将 Meteor 1.3 版本的发布看做 Meteor 团队四年来最大的战略转型,一点不为过。它已将自己的独占道路铺设完毕,开始横向扩展,引入外部的更多车道——包括传统架构和生态环境。于此,Meteor 开始认真面向专业开发者,值得那些曾尝试过但不得不放弃的资深开发团队重新审视。

1. 专业、严谨的代码组织架构

ES2015 (ES6) 标准的细则是由一个小组审查并最终投票敲定的,小组成员由一些公司的代表组成,前天发布的文章中提到的 Geoff Schmidt 便代表 Meteor 团队参与其中。ES2015 是 JavaScript 的新标准,是近五年来最大的一次标准升级,是 JavaScript 开发者的福利。其中 import / export 规则允许代码模块化,Meteor 1.3 版本正式对这一特性进行了支持。

为了向后兼容,Meteor 采取渐变手段,暂时仅将 /imports 目录下的文件视为完全遵守 import / export 规则,其他目录下的文件按原规则走。

遵循 import / export 这一规则,在我看来,至少有两点好处。1.化全局变量为局部变量,明晰文件之间的关联性。虽然编写过程比以前要繁琐一些,但 debug 容易了,review 代码容易了,多人协作也就跟着容易起来,这种专业、严谨的代码组织架构特别适合大型项目。即便是独立开发者,也应该尽力使用这一规则,因为每过两三个月,review 自己写的代码基本和看别人的没嘛区别。2.这是趋势。未来 Meteor 的版本升级会依赖这一规则,很可能有些特性只有在符合 import / export 规则下才能发挥作用,比如 code splitting 和 hot reloading 这类特性。总之,专业、严谨的代码组织结构,既可以让人脑在阅读代码时保持清醒,又可以让电脑在打包代码时符合预期。

2. npm

npm 是什么?是 JavaScript 语境下的 App Store 和 Google Play,诸位设想,没有 App Store 的 iPhone 手机,装不了 app 的安卓手机,你们会用吗?也许会吧,但那仅限于只发短信、打电话、拍照片的小白用户,对于还想刷微博、聊微信等有多样需求的专业用户来说,默认自带的应用是满足不了的。npm 对 Meteor 的意义正在于此。

1.3 版本发布之前,Meteor 是封闭孤岛;1.3 版本发布之后,岛屿有能力与大陆连接。

另外,值得补充的是,为了让小白开发者也能立即用上 npm,Meteor 自带了一个版本的 npm,也就是说,假如电脑上没有单独安装 npm,可以直接 meteor npm install --save package-name 就能将名为 package-name 的 npm 包裹引入现有项目。当然,如果你早就用过 npm,直接像往常那样 npm install --save package-name 就行。

3. React / Angular

上一篇提到过,Meteor 团队宣称,在版本进化中,Blaze, React, Angular 这三个前端框架是地位平等的一等公民。这意味着什么呢,如果你是一名使用 React 或 Angular 的前端工程师,那么就完全有能力胜任 Meteor 项目的前端开发工作。这一官方整合——来自 Meteor 1.2 版本——预示着 Meteor 走上了开放之路,并且在 1.3 版本中再次加以验证。这也正是我为什么在文章开头说『Meteor 值得那些曾尝试过但不得不放弃的资深开发团队重新审视』的原因了。

4. Galaxy

Galaxy 是专门为 Meteor 搭建的云平台,它实现了 Meteor 团队的商业模式,它允许敏捷开发型团队将全部精力专注于业务逻辑。在《有哪些使用 Meteor 实现的商业网站》中提到的 Classcraft 的 CEO, Shawn Young 这么评价 Galaxy: “Before Galaxy, we used to spend over 40 hours per month on devops. Today we spend zero.” 使用 Galaxy 之前,我们每个月通常会消耗 40 个小时在运维上,现在则是零消耗。NitroLabs 的创始人 Max Ferguson 说: “Since switching to Galaxy, we have been able to reduce our DevOps while scaling to support millions of users around the world.” 转为使用 Galaxy 之后,我们在服务来自世界各地百万用户的同时还能削减运维费用和精力。

看出重点了吗,Galaxy 这类云计算平台将运维事宜——程序在服务器上的运行与维护——从团队中解放出来了。这样一来可大幅度削减运营风险。为了运营一个新项目,传统套路是,租服务器,招专业运维,上线看反馈。现在,从项目上传,到正式上线运营,这其中的所有流程被抽象为一个按秒计费的服务。也就是说,如果我打算严肃认真的运营一个项目,我不再需要租用实体机器,不再需要招聘看得见的人才,我只需要租赁看不见的服务。那些服务由世界顶级团队维护,他们不受任何一家公司聘用,但又同时服务着所有的公司。上线后,如果反馈好,一键升套餐或横向扩容以应对高增长,如果反馈不好,说明自己的产品与市场定位有误,下线重来,成本归零,没有繁杂的合同纠纷,没有让人心累的解雇过程。无责任设想未来,每个人都将自己的技能抽象为服务,他们之间随时按需连接,能解雇自己的将只有自己本身。

5. 测试 (Testing)

我个人对这块真不熟,但我知道它很重要。测试的作用是允许代码迭代和多人协作过程中避免出现不符合预期的 bug. 它就像一名代码质检员,随时提醒开发者哪里破坏了规则。当然了,这名所谓的质检员的判断标准需要开发者自己构建出来。

我自己的项目用的是人肉测试,就是只要 1.程序不报错,2.流程走得通,那么基本可以判断没有质量问题。但它低效、不可信,尤其是那些特殊情况,不可能每次走流程都估计到,独立的小项目还好,多人协作起来会特别容易出怪异 bug,并且还很难 debug.

Meteor 1.3 的发布是 Meteor 团队以官方身份对 Testing 进行全面的整合,提供了可扩展的解决方案。如果你熟悉测试,那么在 Meteor 这里,只需要在了解官方 API 具体用途的基础上,过去的测试经验全都可以迁移过来。

一句话,对于严肃的项目,自动测试和人肉测试二者均不可或缺,Meteor 现已提供自动测试的整套解决方案。

6. Apollo

Apollo 是 Meteor 团队面向数据层 (data layer) 提供的解决方案。它虽然是面向未来的新项目,但就目前的进程上看,未来不远矣。官方宣称,一旦 Apollo 正式推出,它将有能力适配所有数据库 (all databases) 和所有后端 (all backends)。这意味着什么?传统架构与新兴架构通吃。

值得注意的是,Apollo 是独立于 Meteor 存在的项目,也就是说,如果你对 Meteor 不感冒,那么一点也不影响你使用 Apollo,它不受限于 Meteor,只不过 Meteor 会将 Apollo 很符合『开发者体验』地整合进来。

不知道你兴奋了没有,反正我是兴奋了。也许是我懂得少,但我能看出来,Apollo 和 Meteor 的整合意味着它允许将我的个人能力延伸至更多的领域,没错,我需要学习、应用更多的技术,这正是我兴奋的原因。我一直想拓展,只不过缺少一条可与现有能力相结合的明晰之路。

对专业开发者来说,Apollo 允许你和你的团队在感受优秀开发者体验的过程中继续使用现有架构,数据库结构设计和数据调取方式将分离开来,前端可高效地、自带文档式地调取数据,后端则不必受制于前端,尽可以肆无忌惮地对数据库的结构设计进行扩展。

对 Meteor 来说,Apollo 意味着允许 Meteor 技术应用于更广大的市场,想象一下,当 Meteor 不再受限于 MongoDB 这一种数据库,当 Meteor 有能力连接更多的后端,哇噻,已然超越我的认知能力了。我只能再三邀请专业开发者团队对 Meteor 重新进行审视与评估了。

对 Galaxy 来说,Apollo 意味着更广大的潜在消费者浮现出来。我猜想,以后即便不是 Meteor 程序,只要数据层应用 Apollo 技术,就可以使用 Galaxy 的服务。总之,钱途无量。