2
回答
【开源访谈】微信高级工程师闫国跃:Mars 的开源之路和我眼中的开源
终于搞明白,存储TCO原来是这样算的>>>   

Mars 是微信官方的跨平台跨业务的终端基础组件。目前已接入微信 Android、iOS、Mac、Windows、WP 等客户端。当初为什么选择开源 Mars?对于开源有什么心得?微信目前有开源其他项目的计划吗?本期开源访谈邀请到了微信高级工程师闫国跃老师,和大家谈谈 Mars 的开源之路,以及老师是如何看待开源的。

【本期嘉宾】

闫国跃,微信高级工程师,目前主要负责 Mars 开源工作。先后参与了微信终端基础组件的开发、微信终端日志系统的建设、微信终端运维门户的开发。

【访谈实录】

1. 嘉宾自我介绍(学习经历、工作经历等)

我叫闫国跃,英文名叫 Garry,2009-2012 年期间,在武汉大学就读软件工程专业,2012 年本科毕业之后,有幸加入了微信团队。在学校的时候,移动开发还没那么流行,那时候主要接触到的是 Java 后台的开发。后来之所以转型到做移动开发,主要是和我们公司的面试风格有关系,因为我们公司的面试主要是考察面试者的思维和能力,而不会过多在意你之前研究的是哪个方向。

加入团队之后,就直接开始了微信终端跨平台基础组件的开发。Mars 是后来陆陆续续开发之后形成的,所以跨平台基础组件是 Mars 的前身。不过我们内部还是把这个项目称为跨平台基础组件,后来才改名叫 Mars,我就负责了 Mars 的开源。

2. 为什么选择开源 Mars?

大家都知道网络是一个 APP 最基础的功能。对于我们来说更是如此,因为我们有海量的用户,这几年也是遇到了各种 “奇葩” 的问题,在这过程中,遇到问题我们都会努力去解决,也和手机厂商、移动运营商等打过交道。

现在回过头看一下这几年所做的东西,自我感觉还是挺有价值的,而且我们也愿意把这些成果拿出来和大家分享。

3. 开源后在维护方面带来了哪些麻烦?

开源后的第一个月确实挺麻烦,在第一个月里,当时我们两三个人几乎投入了全部的精力在 QQ 群里面回答别人的问题,处理 GitHub 上的 PR 和 issue。但后来慢慢的,随着回答的问题越来越多,我们发现有很多典型的问题,所以我们把这些问题整理归类好,放在项目 GitHub 主页的 wiki 上。这样,消耗的精力也就越来越少了。

第一个月对这个项目的维护也算是我们的工作内容,但毕竟不能长期来做这些工作,所以对于开源的项目有一个好的运营模式就显得十分重要了,毕竟你只能花少量的精力去处理这些事情,但是又要保证代码的质量,而且还要不停地去迭代。

后来我们想到了一个这样的运营模式:因为项目有一些特性开发是不希望外部用户立即看到的,所以会有一个内部的分支,但是内部分支又必须和外部分支保持同样的代码。因此我们认为,外部分支需要有一个开发(dev)分支,这个分支主要是用于给别的开发者提交 PR,开发分支不代表是稳定的代码。

对于开发分支的代码,我们会把它拿到内部分支进行灰度测试、在微信上进行灰度测试,如果没问题了,在微信大版本更新发布之后,经过验证还没问题的话,我们会把这部分代码同步到外部分支。这样操作下来,流程可能有点长,迭代速度和响应速度也没那么快。但我们最起码能保证所有我们发布的代码都是经过微信几亿用户验证的。

所以可以看到,我们的主要精力是花在了内部,比如工作上面。对于外部的工作,我们就只需要花部分的精力把代码同步过去,其实这个同步的工作也是通过自动化的脚本完成的,而无需通过人工完成。

4. Mars 主要解决的开发痛点是什么?

主要有三点。

第一个是国内比较复杂的移动网络和弱网络环境。其实国内的网络比国外的网络复杂很多,主要的原因是人多、地方大。人多的话就会导致设备争夺资源,地方大的话布置信号塔就会比较麻烦,还有就是移动网络的一些特性导致国内的移动网络质量没那么好。

第二,Mars 是针对移动终端进行设计的,移动终端包括很多方面,例如前后台、休眠和唤醒等。

第三,对于这种组件的开发,假如为每个平台都开发一次,无论是前期的开发还是后面的维护,都会浪费很多人力,而且会很容易导致一个问题,因为对于同一个方案,不同的开发人员开发出来的可能会不一样,这就有可能导致策略不一致。Mars 是一个跨平台的组件,业务性无关的。如果拿来使用,从这个业务切换到另一个业务,或者从这个平台切换到另一个平台,只需要做基本的最小化修改即可。

5. Mars 开源后,团队是如何对它进行维护的?有什么心得和经验和大家分享?

我认为,刚开始把项目开源出去的时候,不花费一定的时间和精力是不可能的。但关键是要有一个好的运营模式,这点十分重要。如果找不到一个好的运营模式,会很难继续把项目维护下去,有了一个好的运营模式之后,才可以保证项目的活力。

另外,项目也一定要有好的文档和 DEMO。不然,会一直有不同的开发者不停地向你请教问题。

还有一点就是,既然选择了开源,就相当于把项目拿出来给大家审视。如果存在着同类的产品,就需要有 benchmark,即和其他同类产品的对比。因为如果有别人来质疑你,benchmark 是最有说服力的。

其实刚开始我们也受到过类似的质疑。比如 Mars 中的日志模块,有人就会质疑,现在已经有很多类似的东西了,比如 log4j、log4cpp,你们为什么又做一个?你们喜欢重复造轮子吗?这时候,把 benchmark 放出去就比较有说服力了。因为毕竟不同的东西有不同的应用场景,而 benchmark 恰恰是对这个最好的证明。

6. 目前这个组件是把全部模块都开源了还是只开源了一部分?

目前我们是已经把全部模块都开源了,不过虽然开源了全部模块,但是毕竟有一些内部代码是不能开源的。

因此目前我们需要对 Mars 做一些比较好的设计,比如说解耦合、接口做通用化等。这样,即便我们有些东西不方便开源出去,大家也可以在它的基础上去开发。即把 Mars 作为一个更底层的库,而不是修改它,是将 Mars 作为一个基础库来使用。这也可以保证 Mars 是我们在使用的东西。

7. 微信如今已开源多个项目,涉及到数据库、框架等多个领域,如何看待开源带来的影响?

对于外部来说,技术上,开发者肯定是受益的。因为他们毕竟不一定有机会在这么大的用户量和业务上去实现这些技术。

对于我们内部而言,也肯定是有好处的。因为大家都说微信的产品做得好,不过技术水平如何可能不太了解。所以现在就相当于把我们的技术拿出来给大家观看,让大家来评判。

关于开源,还有一个共同的好处是,会有很多高水平的开发者产生一个正回馈,他们会帮忙发现问题,也会帮忙解决问题,这对我们是好处的。

对于个人,这也有利于我们的个人发展。两个技术人员交流最直接的办法就是代码,所以开源给我们提供了一个更大、更宽阔的平台去和其他技术人员交流。没把项目开源出去之前,写代码的时候可能只考虑到实现功能即可,但开源之后,考虑到代码会有很多人看,因此就会鞭策自己要把代码写得更好,要用更优雅的方式去实现,无形中也就提高了对自己的要求。

8. 微信目前有开源其他项目的计划吗?

目前是有计划的,但具体时间暂时还没确定。刚刚也说了,开源只要做得好,各方面都会有受益。

去年我们开源了热补丁框架 Tinker 和网络框架,这几乎是微信 APP 最核心的部分了。今年打算把微信客户端的数据库进行开源,这是目前在移动端(包括 iOS 端和 Android 端)都在用的数据库,但是现在还不能确定时间,应该会在今年做这件事。

9. 有些公司对项目开源之后,就不再维护了,对此你怎么看?

就像刚刚提到的,要时刻保持开源出去的项目是自己也在使用的。就国内的情况而言,基本上是业务驱动技术发展,所以当内部不再使用开源的代码,外面的也很难去顾及,毕竟公司内的工作要花费不少的精力。

再者,国内不少公司的开源还是被 KPI 所驱动,带着很强的功利性。这种驱动会导致一个问题,因为 KPI 只关注项目是否已经开源了,所以很多时候很多项目把代码开源出去就结束了,变成了大量的 “僵尸” 项目,导致开发者不敢使用,也降低了公司的信誉度。

10. 结合你的经验,你认为其他公司在开源项目的时候应注意什么?

第一,开源出去的项目要有价值。无论是对于用户还是开发者,能带来价值的项目才是一个好项目,而且这个价值不能是自己主观认定的价值,而应是要有真正的用户和业务来证明。

第二,开源出去的项目相对于其他同类项目要有优势。因为有些团队的优势可能是在海量用户上,有些团队的优势是在大数据上,只有把自己最有优势的领域的项目开源出去才最能造福开发者。

第三,开源出去的项目要保证有活力。不能把项目开源之后就撒手不管了,让其变成 “僵尸” 项目。最开始时不投入大量精力是不可能的,但是我认为每个团队都可以找到适合自己的运营模式,即花最少的精力去维护开源的项目。

目前我们的官方项目也是一直有在维护,因为我们全都有在使用。不过 Mars 可能比较特殊,因为有些东西会涉及到产品特性。这个和我们开源的热补丁框架 Tinker 不一样,因为 Tinker 是没有内部代码的,所以这也保证了它的开发始终是基于外部的代码。

11. 你认为国内开源的现状如何?你理想中的开源是怎样的?

和前几年相比,目前的开源是越来越好的,越来越受国内开发者重视了,而且很多个人开发者也愿意把自己的优秀项目开源出来。据我的观察,在国内,社区氛围也整体朝着好的方向前进。整体上,也有越来越多的公司重视开源。但依然存在部分由功利性驱动的项目,它们带着很强的功利性。

还有就是开发者中也存在着部分伸手党,他们总是不经思考地提问题。比如我们的开源项目已经在文档中列出了很多问题和说明,但他们不会去看,上来就问该如何解决他的问题。他们期望得到我们这边的回答,可我们毕竟人手紧张,而且即使我们全职维护一个开源项目也做不到时刻去回答使用者的问题。况且很多问题已经归类到文档中了,只需动动手点击查看就能解决。

虽然有一些不那么好的地方,但我依然认为未来是会越来越好的。

关于理想中的开源,对于我们技术人员来说,理想中的开源其实就像一种信仰,但不能说不带一丝功利性。毕竟如果在公司内做开源,没有一点功利性,会很难继续下去。但我不赞同为了某种功利性的目的去开源,而应该是把一个开源项目做好,这样很多东西自然而然就来了。

这里其实涉及到一个动机的问题,比如我的初衷是想着做好这个开源项目,那么很多东西自然就会不约而至,因为我不太强求某些东西。这里,有一句我很喜欢的话想和大家分享:但行好事,莫问前程。

关于开源,还有一个比较重要的是,不能只是把代码开放出去就可以了,这只是最基本的原则,还得提供便于理解的文档、DEMO 等。作者也需要维护、不停地迭代。

我理想中的开源社区也没有那么多伸手党,因为开源项目的 owner 把项目开源出去,是希望把大家连接在一起,互相学习,共同成长。

举报
局长
发帖于6个月前 2回/2K+阅
顶部