清风谈豆瓣CODE、Git与工程师文化

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

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

   

1. 大家好，欢迎来到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，开始重视这种代码质量，真正的重视代码质量。开始说重视一些团队内部工具的开发，就开始知道工程师不一定只按条例去管理，咱们应该有一个良好的工具。让大家在一个工具上去工作。就我老说一句话，就是说互联网公司，都是做一个这种用户体验很好的产品，去让用户用的特别爽。但是公司内部都是用特别原始的工作方式去工作，高科技公司还是自己的工作流程，应该也有很方便的工具，用户体验很好的工具去工作。