BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

清风谈豆瓣CODE、Git与工程师文化
录制于:

| 受访者 清风 关注 0 他的粉丝 作者 候伯薇 关注 0 他的粉丝 发布于 2015年1月14日 | Google、Facebook、Pinterest、阿里、腾讯 等顶尖技术团队的上百个可供参考的架构实例!
14:56

个人简介 2012年起,清风开始在豆瓣主导CODE平台的开发。CODE是豆瓣内部一个基于Git版本控制系统的协作平台,最初是豆瓣为了解决自身的开发流程、代码管理、上线等问题开发的。这不是一个公司项目,但仍然聚集了众多的豆瓣工程师参与其中。截止目前,CODE已经托管了豆瓣内部几乎所有项目的代码。 在豆瓣内部,CODE的主要用途包括:存储代码仓库; 代码审查,工程师日常沟通;持续集成,上线系统的联动。

QCon是由InfoQ主办的全球顶级技术盛会,每年在伦敦、北京、东京、纽约、圣保罗、杭州、旧金山召开。自2007年3月份首次举办以来,已经有包括传统制造、金融、电信、互联网、航空航天等领域的近万名架构师、项目经理、团队领导者和高级开发人员参加过QCon大会。

   

2. 您先自己介绍一下自己。

清风:我叫清风,这次来QCon演讲的主题,主要是讲在豆瓣做的那套CODE平台,以及如何在公司内部组建虚拟团队。我在豆瓣之前工作了五年,在豆瓣之前是在新浪工作了五年,一直差不多都是在互联网这个行业。

   

3. 您是在互联网行业工作了十年多?

清风:十多年,是是。

   

4. 那其实我之前也有了解到CODE平台。因为CODE平台在开源的时候,其实感觉是一件,对于程序员来说,是一个比较好的一件事。当初CODE平台是在什么样的一个背景下开始这样一个项目?

清风:其实主要当时就是说豆瓣工程师在逐渐变多,差不多是从30人变到300人左右。这样的话,工作流程会跟原来截然不同。就是说30多人的时候,我们可以在一个屋就可以把会开完,那么300人的时候就不太可能。而且每个工程师都是打到产品线里的,那么其实名义上不再存在一个所谓的技术部了,可能所人都是在产品线内。

但是从技术这边的角度来讲,是希望大家有一个,仍然能够充分沟通和交流的一个地方。比如说你一个代码,我还是希望有很多人来Code Review,而不仅限于你的部门内部。而且有一些小的部门可能也许没准只有一个工程师,那么这样他没有人来对他的代码去做这种Review。所以我们当时就比较期望说有一套工作流程,有一个良好的Review机制,所以当时我们就是觉得开源社区,就GitHub那套流程,或者说在GitHub更早,就是大家开源社区一直用的这套工作流程,我们觉得就是最适合豆瓣的。这样的话我们就需要一个工具,需要一个跟GitHub类似的工具,所以当时我们就是说尝试去做一个。后来就发现也可以做,就一直就开发了这套平台。

   

5. 您觉得在这个CODE平台它的开发过程里有什么样特点,是不是体现了豆瓣的那种很浓的工程师文化的这种特性?

清风:是,我觉得这真的就是我们就最开始做的时候,其实也没有想到说,平台能够做得,功能还挺丰富的。开始就是想先尝试试试看,因为这套开发最大的特点,就是说它是没有全职工程师的,所有的人都是用自己的业余时间,然后去把这套系统整个开发完的。这个真的其实是需要,就是工程师很热爱这件事情,就是每个人都觉得这个事还挺酷的,我做完这个工具,可以给其他所有的工程师去用。因为日常做产品开发,它毕竟大部分需求不是自我产生的,可能是由PM产生。然后有很多东西也没法把控,但是做这种工具型开发,就是程序员的把控力其实会更强一点。因为他是需求的提出者,也是实现者。然后他还可以加入很多很Geek的元素,这样的话我觉得体现的还是挺充分的。

   

6. 那CODE平台现在它大概有哪些功能?

清风:简单描述的话,GitHub有的我们肯定全有。还有个别GitHub肯定没有的,我们才有。因为它毕竟是一个在企业内用的工具,对,所以的话它一定有我们一些比较独特的一些功能,可能GitHub都不会去有。比如最典型的就是API,GitHub的API肯定是比较Public的那种,就是它比较Generally,比较得照顾到通用情况。但是我们的API就可以相对比较私有化一点,就是效率会更高一点,跟我们的一些系统去做集成。

   

7. 其实就是针对豆瓣当时具体情况去做的?

清风:对,举个最典型的例子,就是关于DIFF这件事,还是Code Review。因为我们当时上这套平台的初衷就是为了增强Review,那么Review是我们核心中的核心。所以我们关于DIFF展示这一块,其实有很多小的这种细节在里面。这些有可能都是,有的都是GitHub都会没有的,或者说有的异曲同工。就是我们发现我们有了,后来他们也有了。比如最早我们有那种Side By Side DIFF,就是竖着那种DIFF,GitHub最早是没有的。那么为了照顾这种场景,我们加了。比如说展开,就是CODE Review的时候,毕竟公司的项目,代码量其实是比较大的,很少有人能记得所有的代码。他要看一个DIFF的时候一定是需要一些上下文的。他需要不断的展开那个代码,需要能看到上下文,还有是什么样的代码。他才能做准确的Review,等等一些小的细节在里面。

   

8. 就是CODE其实跟GitHub它俩是在相互借鉴?

清风:不敢这么说,把我们抬的太那个什么了。还是最开始我们是借鉴GitHub为主,只不过做的过程中,因为企业内部的需求,一定有自己比较独特的需求在里边和不同点。因为GitHub毕竟是一种社区,一种比较Generally的社区。那我们这个工具毕竟是要完成豆瓣的整个工作流程,就要更贴合豆瓣的使用,所以一定会走上一条相对不太同的道路。

   

9. 还有一个,就是Thomas Yao,他的做的那个GitCafe,那他跟CODE你觉得相互之间有一些什么相同的,或者不同的地方吗?

清风:因为GitCafe的话,我觉得其实也是做的很好的一个产品,就从我交流下来,GitCafe是国内唯一一个这种原创开发的产品,就是从头自己写的,其它的有很多产品,可能都是从某一个开源项目改的,我觉得都不是特别好。差别就是在于GitCafe也是跟GitHub类似,从一个公有社区起家的,那么它很多东西,跟GitHub很类似的,而且也做到基本的一致。差别还是那个差别,国内很多代码托管工具,可能都不是直接从企业内部做的,都是直接像GitHub那样,从一个社区做得,所以大部分都跟GitHub是类似的。但是我是觉得像GitCafe,他们也是有计划要推这个企业版,也会针对企业的一些情况去做一些这种定制和一些东西。因为我现在也在GitCafe做这种技术顾问,我觉得可以把CODE的一些经验,可以放到这个GitCafe里。

   

10. 当初你们在两周年的时候,情人节的那天开源的时候,当时是为什么想把这个东西给它开源出来?

清风:开源是这样,其实当时的初衷,因为豆瓣毕竟不是一个做工具出身的公司,就是比如像GitCafe,它一起家它就是做这件事,那这件事是它的核心业务。那么CODE是豆瓣内部的一个工具,它永远也不可能成为豆瓣的一个核心的功能。那么随着人员的流动,随着等等一些东西,这个工具就是也许没准就消亡了,或者也许这个工具就没法被更多的人看到。因为我们觉得这个工具做得还蛮好的,所以当时就说,干脆就把它开源。当时主要是想,因为也没别的什么办法,就干脆就开源算了,让大家可以更多的看到它。而且Python社区也没有对应的一个工具,我们觉得可以开源一个版本出来。

   

11. 你当时参与CODE开发过程中,你觉得您的工作时间会有百分之多少的比例放在这个?

清风:其实特别不稳定,就是综合算下来,可能差不多得有一半的精力在这个上面。但是得看事,比如说最近特别忙的,有别的事务的话,那CODE可能我的精力也许连1%都占不到。最近可能安排的好一点,把别的事情挡一挡,或者往后拖一拖。我可能最近也许有百分之一百的精力都在CODE上,所以它特别不稳定。

   

12. 有各种KPI的指标压力?

清风:没有,因为豆瓣从我走,到创始开始,一直都没有这个KPI这种东西。

   

13. 工程师文化其实更适合我们这些技术的人去发挥各自的更大的潜力?

清风:对。因为一旦有KPI的话,尤其是定的比较死的那种KPI的话,工程师,就人吗很正常,他一定会盯着KPI去走,他就不会干别的。也没办法,你钱是跟这个挂钩的。确实一定程度会抑制工程师的这种创造力,这个点其实也是我这次QCon想来分享的。但是这个也得看公司自己的一个运作方法,也许没有。因为还有一个点,有一个大前提,就是豆瓣的工程师说实话,真的是个人素质非常高的一批工程师。因为没有KPI的危害在于,如果这个人自律性不够强,那他就太容易偷懒了。上KPI的一个原因,可能就是工程师自律性不强,那么我必须拿KPI去管着你们。但如果是一个自律性很强的团体,就即使你不给派活,我也一定会找活。如果是这样的一个人,其实你真的没有必要用KPI去管理他,不如让他去发挥他的创造性。

   

14. 反而去做他最感兴趣的这块?

清风:对对。因为当时豆瓣内部,其实除了CODE这个平台以外,其实还有好多工具。我们管我们这个虚拟团队叫黑科技魔法部门。因为一个企业内部,你要运作起来其实要有好多工具,你也看到现在有很多工具的这种公司创业,如Trello,包括GitHub、Basecamp,包括国内的GitCafe。这些公司,其实都是做工具。那么企业内部其实就需要这些工具,我们也需要Trello,我们也需要GitHub这样的工具。买当然都是一种途径,那么还有一些工具可能市面上也没有现成的,或者当时那个版本可能也很难用。那么我们可能内部自己就会做一个,一定都是这样。除了豆瓣以外,很多互联网公司我了解到,其实也差不多都是这样的。

   

15. 做一些最适合的自己的工具?

清风:对对。但是你说你每做一个工具,就成立一个部门,这可能是大公司的做法。对于我们来讲,肯定是不现实的。真的就需要大家贡献一点业余时间,然后去把它给做出来。

   

16. 那CODE在开源了以后,以后还会继续再对CODE贡献一些代码吗?

清风:这个实话实说有点难。是这样的,因为现在CODE的开源,其实跟豆瓣内部那个版本是截然不同的。因为内部工具一个最大的问题呢,就对内部资源依赖的非常重,就当是那个CODE其实依赖了豆瓣内部的云服务DAE;然后依赖了豆瓣内部很多接口,然后很多就是比如说关于存储、数据等等一些东西,都是调用豆瓣很成熟的一些东西。所以的话,其实我们开源那个版本,不是内部用那个版本。因为没法直接把那个开源。

   

17. 我们把所有东西全都开源。

清风:对,所以当时我们已经是借着开源CODE,把豆瓣好多基础服务其实都开源了,什么连接数据库的,什么乱七八糟的一些东西其实全开源了。但是发现仍然还是不够。除非我们把DAE也开源,但是DAE因为是个私有云,还确实有一些不太方便开源的地方,所以当时那个开源的版本,其实是个重置版,所以功能几乎没有。豆瓣内部现在我了解到的,也有一些同事还在继续的贡献一些代码。但是从我个人目前的精力包括各个方面,其实没有太多时间去做这个事情了。

   

18. 其实您对于CODE平台付出了很多。那您对这个平台开源之后,您有没有比较好的一些期望?

清风:其实从我目前来讲,就是期望是这样的。其实我现在又觉得呢,工具真的只是一方面,可能也是这次来QCon想分享的。因为工具早晚还得要升级,还得要变化,就像Git现在很火,但是可能也没准还没有早年间的SVN火,它其实一代一代的。也许再过五年,还会有一个新的工具诞生了。可能像GitHub这样的工具又没用了,因为换了一个版本控制的工具,就意味着换了一种工作流程。其实可能我觉得就是这两年做CODE下来积累的经验其实是蛮重要的,我现在也看到很多互联网公司,开始重视这种过程改进,开始重视Code Review,开始重视这种代码质量,真正的重视代码质量。开始说重视一些团队内部工具的开发,就开始知道工程师不一定只按条例去管理,咱们应该有一个良好的工具。让大家在一个工具上去工作。就我老说一句话,就是说互联网公司,都是做一个这种用户体验很好的产品,去让用户用的特别爽。但是公司内部都是用特别原始的工作方式去工作,高科技公司还是自己的工作流程,应该也有很方便的工具,用户体验很好的工具去工作。

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT