技术人攻略访谈三十二| 清风:豆瓣神组小组长,日式萌神程序员

文:Gracia,摄影:周振邦 (本文为原创内容,部分或全文转载均需经过作者授权,并保留完整的作者信息和技术人攻略介绍。)

导语:本期采访对象清风,前豆瓣技术总监。豆瓣以小清新风格,和独特的工程师文化在国内技术圈独树一帜。过去四年半里,清风亲身经历了这家创业公司的高速发展,从30多人小团队,成长为近500人的成熟企业。这期间,他主导了一项重要变革:用开源项目运作方式打造出豆瓣内部代码协作平台CODE,推动开发流程成功从SVN转向Git。版本系统迁移是牵一发而动全身的大工程,涉及围绕SVN的整个生态系统迁移,工程师技能转型,以及管理流程及文化适应。其难度和工作量巨大,即使是豆瓣这样极客范儿的公司,也花了两年时间才完成。

诞生于开源世界的版本控制系统Git,由Linux之父Linus Torvalds亲自设计和开发,以实现对庞大复杂的Linux内核项目的高效管理。这个分布式版本控制系统具有强大的分支管理能力,无须操心数据备份,并能有效避免因代码的频繁提交而中断工作。Git高效的协作模式带来开发效率的极大提升,以及团队成员之间的有效沟通。凭借这些明显强于SVN的特点,Git迅速在开源界流行开来。

基于Git的代码托管平台GitHub应运而生,不仅有Eclipse、jQuery、Ruby在内众多知名开源项目迁移至GitHub,并且孕育出BootStrap、Node.js、PhoneGap、Docker等大量明星项目。新工具普及带来生产力解放,开源世界的大门从此敞开,赋予普通人自由使用和修改代码的权利。协同成本大大降低,任何人都可以Fork代码、创建分支,用Pull request方式参与开源项目的贡献。这场代码民主化运动,是去中心化的互联网力量对核心智力生产流程的一次渗透,借助社交化传播渠道,让每个优秀创意,都能带来整个领域的机会提升。

清风说自己身体里流着创业的血液,凡事喜欢折腾,而且都做得有模有样:在豆瓣白手起家倒腾出一堆新部门,参与国内最早的比特币项目,就连玩豆瓣小组,也能玩出一个30多万粉丝的“吃喝玩乐在北京”(什么!真的没有听说过!那你玩陌陌吗?)。在以贴标签文化著称的豆瓣,吃喝组组长清风喜欢在自己“白羊座”的标签之前加上“纯洁”这个形容词,同事的标签则是“表面纯洁的白羊座”、“萌神”、“卡卡西”。清风是野路子出身的非典型程序员,早在18岁那年就见识了互联网泡沫的疯狂和幻灭,于是在他典型的白羊座式的萌里,还看得到过尽千帆。

技术人攻略:你在豆瓣工作的时候做了开源代码协作平台CODE,能讲讲当时做这件事的背景吗?

2009年我离开工作了四年半的新浪,想去一家技术范儿特别重的公司,其实心里只有一个目标,就是去豆瓣。作为豆瓣的深度用户,我非常喜欢这个网站。05年在Python User Group聚会上,听阿北介绍过豆瓣的技术架构,豆瓣是国内第一家,也是惟一一家大规模用Python搭建主体业务的公司,我希望能在Python上钻得更深入。加入豆瓣时,我刚好是它的第36名员工。

我在豆瓣待了四年半,眼睁睁看着它从30多人变成了400、500人的公司(技术团队超过300人)。发展的每一个阶段,管理方式都会有相应的变化。在豆瓣的第一年,技术部总共才十来个工程师,当时采用接单式工作法:所有工程师在一个池子里,任何产品要做新功能,就看哪个工程师有时间,整个管理很轻。

公司接近100人规模时,这种方式的弊端出来了,工程师和产品没有关联,缺乏归属感,沟通效率极低。于是改用产品线管理方式,每条产品线配备一个包括产品、运营、开发和测试在内的全编制团队。同时期还诞生了几个公共部门,如Anti-Spam、商务支持、公共服务、平台组和算法组。

组织结构的变化影响着开发流程和工程师文化。归属感的问题解决了,但技术的横向交流变少,时间长了不免出现重复造轮子的问题。

为了解决这个问题,一开始是想办法把工程师聚到一起,例如豆瓣Happy Day活动:每个季度腾出一天工作日,让所有工程师放下手里的工作,一起来写代码。这个活动搞了好几届,分了不同的主题,包括类似ACM的算法大赛,Hackson大赛,还攒过一次3D打印机。这个活动要求所有人停下工作,成本非常高,缺乏持续性。

后期我们希望用一套流程和工具来帮助工程师沟通。豆瓣的工程师Geek范儿很足,发明一套流程他们绝对不会用,于是自然而然想到了GitHub。GitHub在开源界广受欢迎,开源文化也和豆瓣的一贯气质最为符合。GitHub严格意义上不只是个代码托管平台,而是一个程序员社交平台,它那套机制之所以运转得好,真正原因是让工程师实现了顺畅的交流。按豆瓣工程师人数算,Github企业版的服务一年下来得花50万人民币,关键当时它很不稳定。于是只好下决心自己开发一套,这就有了后来的豆瓣CODE。

技术人攻略:做豆瓣CODE的过程中,最大的困难在什么地方?

从立项到整个开发流程都转到CODE上,前后一共用了两年。需要完成两件事,一是搭建一个类似于GitHub的代码平台,二是把整个开发流程从SVN转到Git。回想起来,这个过程真不是特别容易。

第一个比较大的困难是没有人手。我被耿老(耿新跃)和洪教授(洪强宁)赶鸭子上架,做了这个项目的Leader,但却是个光杆司令,手下一个专职的人也没有。2012年情人节,我写下了CODE的第一行代码,和洪教授带着两个实习生,用了一个星期,基于Python开源问题跟踪系统Trac改出了一个demo。界面巨丑无比,但功能都有了,于是咬着牙开始用。

推广第一步,先从自己的产品线开始用。我带的产品线很多,例如Anti-Spam,商务开发、东西产品线,另外洪教授的平台组也在用。当时的做法是边做边迁移,边加功能,完全是配合着需求,边走边造轮子的过程。

那段时间我几乎把50%的精力都放在CODE上,贡献了大量代码。但一个人力量有限,不可能实现所有功能,于是开始忽悠更多同事参与开发。GitHub当时正好拿了一笔融资,估值到了7亿,我于是见人就画饼:你们想参与一个价值7亿美金的项目吗?当然并不是完全山寨GitHub。最后统计共有48人参与了项目,完全按着开源软件的节奏,大家见缝插针,凭着热情和爱好,把CODE成功地做了出来。

做这件事的第二大难点,是统一大家的思想。SVN转向Git不仅涉及使用习惯的变化,更重要的是,围绕SVN构建的整个生态系统都需要随之而变。豆瓣很早就开始用SVN,并围绕它打造了很多工具,包括上线系统、持续集成系统、任务管理系统都和SVN绑定,相当于所有这些代码都要重写,涉及巨大的工作量。

Git的学习曲线比SVN高很多,要想上手,除了需要掌握百条左右的Git命令,还得了解GitHub这套流程规范。即使在豆瓣这样Geek范儿的公司,也并不是所有人都参与过开源项目的开发,熟知Pull Request那套流程。一些积极性不高的员工难免会产生抵触心理,这时候就需要借助公司的力量,从上到下推动这件事。一方面在产品线内部培养积极分子,另一方面提供相关的培训,再有就是采取一定强制措施,从公司层面强制规定使用Git。

技术人攻略:豆瓣的工程师文化,对做成CODE这件事有多大帮助?

国内号称有工程师文化和氛围的公司,豆瓣真得算一个。在豆瓣,工程师文化不是形而上的概念,而是落实到通过工具,而不是通过制度去解决问题的行为方式。创始人阿北是技术背景,包括洪教授在内的头几个员工,有非常优秀的工程意识,他们一开始树立的高度,决定了整个公司延续下来的文化。

我到现在都还记得,刚进豆瓣的第一天,我的工作不是开发产品,而是和同事做一个方便前端工作的框架。豆瓣很早就已经有一套上线系统,即使当时公司的规模还那么小,而且即使在那么早期,大家都会主动写单元测试。

CODE之所以能做成,是全豆瓣所有人的功劳。几乎每个人都愿意去做过程改进这件事,只要环节中有浪费,有不爽的地方,大家就会想办法解决。各个技术公司都在强调工程师文化,但要真正把这件事做起来,不能空谈,需要有一些形式和具体可执行的东西。比如每周的技术分享、促进工程师沟通的工具,甚至晚上的吉他班。什么是工程师文化?代码才是最重要的!一家不重视代码的公司何谈工程师文化。

技术人攻略:根据你的观察,国内公司和程序员对Git的接受程度如何?

国内的Geek程序员已经开始用GitHub,但仍然有大量的人从没接触过开源。找我做咨询的一些公司,程序员还在用Windows做开发,即使在豆瓣这样的Geek公司,到后期也至少有一半的技术人没有参与开源。所以开源这件事,在中国还仅限于小部分人。我和国内互联网及传统软件公司的人都交流过,豆瓣转到Git尚且用了整整两年,对于那些规模大得多,Geek比例低得多的公司,推广难度更不可估量。

国内的互联网公司很缺人,但缺的是A类和B类人才,这类人才不可能通过大学教育教出来,只能靠开源文化的传承去熏陶。GitCafe、技术社区,以及国内做黑客马拉松的公司,大家都在做一件事:通过这些活动和产品,让更多人接触到开源文化,帮助国内工程师尽快成长,变成那种更加Geek的程序员,这将是个很漫长的过程。

2003年我加入新浪,跟着老黄(黄冬)推SVN,那时候还没有公司用版本控制工具,都是每天复制一份文件夹,用FTP上传到服务器。那会儿大家的疑问是:为什么要用版本控制工具?十年过去了,新的问题变成:应该要用版本控制工具,可为什么要用Git?这个变化在我看来已经是进步了。再举个例子,原来很少有公司写单元测试,现在这个比例虽然仍不高,但起码有人愿意开始写了。过去京东、大众点评都是基于.NET架构,而现在都在转向开源架构,阿里这样的公司更是为开源做了很多贡献,去IOE就是阿里发起的。这些在我看来都是好现象。

技术人攻略:你经历过豆瓣比较完整的发展过程,解决了开发流程问题之后,还遇到哪些问题?

2012年业界开始兴起O2O概念,豆瓣那会儿的整体方向是接点地气,所以也开始涉足这个领域,例如卖电影票,做电子书,参与音乐节等。线上业务一旦和线下挂钩,就得铺人。例如卖电影票得做交易系统,对接所有的电影院平台和取票机,每家的平台都不一样,业务复杂度很高。除了技术,还得铺大量的运营人员,给运营同事开发管理后台、便利工具等等,都需要人,于是公司开始大规模扩张。

扩张期招来的人,不可能都是Geek,校招又进来了很多小白。新人直接下放产品线后,出现了很多问题。于是设计了一个新人训练营,在一个月培训期里,做集中式的工具讲授和开源文化的普及,效果好了很多。

回头看豆瓣这两年的战略发展,移动客户端和O2O这两波浪潮都没抓住。这两个领域有个共同点,恰巧是豆瓣不太擅长的地方。PC互联网时代,不用投钱推广,通过SEO就能从搜索引擎获取大量流量。而移动互联网时代,免费流量没了,需要铺人做渠道,才能把下载量做上去。O2O也类似,不可能借助免费的渠道起来,必须要铺人、铺渠道。

时代变了,但我们没有顺应去变,所以在这两个关键点上豆瓣都做得不太好。这其实是个后知后觉的事,做的时候对情况估计不足,比如豆瓣电影的口碑很好,本想着卖电影票是顺利成章的事,但真正推起来的时候,才发现影院并不买帐。虽然豆瓣在扩张,但总体人数和团购网站比还是小得多,在地推的时候并不占优势。

技术人攻略:听说你比较早就进了互联网行业,还经历过2000年互联网泡沫,当时是什么情况?

我出生在北京,接触电脑非常早,小时候就经常去中关村买软盘,眼睁睁看着这条街一点点变化,从这里感受到IT前沿的力量。中关村诞生了许多牛人,刘强东当初就在那开柜台,爱国者的冯军也是从卖键盘、鼠标这样的小生意起家,还有王志东、王江民这样的传奇人物,我们都听着这些人的传说长大。

高一开始上网之后,不知怎么就莫名其妙买了本杂志,跟同学一起学HTML。当时正好有一些海归回国创业,依靠HTML这个“高级技能”,我们接了些兼职工作,一天能挣150块钱。当时小,能挣这么多钱非常开心,于是决定退学。结果自然是没退成,只好偷摸着搞网站。我们喜欢玩游戏,手上也有很多相关资源,就做了个游戏资讯网站。

高考结束当天,我和同学就在潘家园租了一房,开始折腾自己的事。当时主要的收入来源,是给大网站的游戏版块提供资讯和下载资源。没想到自由的日子没过几天,惨痛马上就随之而来。2000年互联网泡沫破灭,大批公司倒闭,许多人头天还上着班,第二天桌上就放一信封,里头结了一月工资,被裁员了。我们自然也失业了,那时候刚18岁,以为这行业就跨了,特别迷茫。那种感受特别深刻,以至于我到现在也忘不了,经常告诫初入职场的同事,要随时做好明天公司就倒闭的准备。

回想那段经历,唯一比较幸运的是比较早接触了技术。当时没有人指点,就是纯野路子,各种瞎学。创业这事黄了之后,我也没去上大学,继续捣鼓编程。我算是被互联网伤过的人,后面找工作一直很纠结,直到2003年底进了新浪,才算是真正成为了正规军。

技术人攻略:如果不考虑现实因素,你想做什么事?你的兴趣爱好是什么?

无论是否考虑现实,我都会做和技术相关的事。中学时期学了6年日语,深受日本文化影响。日本人强调工匠精神,我很欣赏把一个东西从无到有,并且很精细地做出来那种过程,这可能是我喜欢做技术的原因。但严格说来,我不是死抠技术的人,因为技术始终要服务于产品。

我是野路子出身,属于非典型程序员,喜欢折腾各种各样的新鲜事物。在豆瓣的时候,就喜欢揽事儿,公司自由度也高,往往白手起家倒腾出一个部门,例如CODE、商务开发、东西、Anti-Spam,包括豆瓣读书最早的Kindle版本,都是从无到有做出来的。

除了工作,业余时间我还掺和了很多外界的闲事,搞出了“吃喝玩乐在北京”豆瓣小组,参与国内最早的比特币项目,帮搞艺术的朋友做3D。我身上流着创业的血液,根本闲不住,凡事只要新鲜、好玩,我就愿意做。

我的兴趣爱好很广泛,喜欢踢球、写代码、参加各种线下活动。我非常喜欢生人社交,可能莫名在哪儿看见一个帖子组织聚会,就会去看看。我很愿意认识完全陌生的人,了解完全没有关注过的领域。因为这个原因,交了很多跨界的朋友。我始终觉得,人需要对外界保持一定的新鲜感和敏感度,广泛接触的新事物反刍回来能帮你做好现有的事。

技术人攻略:你兴趣爱好这样广泛,怎么平衡深度和广度的问题?

我一直觉得人的发展是广广深深的过程,广度打不开,深度也会受限制。因为可能挖着挖着就遇到一个特别硬的石头,这时候需要往旁边走,把眼界拉开,才知道应该如何去深。深度这件事在我看来,不是你把MySQL的源码研究得特别透,就叫有深度。我所理解的深度是对整个行业和生活的看法,先要广泛地接触这个世界,然后再讨论更深层的东西。

我们的时代发展得太快,有可能你今天研究的所谓深度,就是明天要淘汰的东西。还是举MySQL的例子,很多公司确实缺资深DBA,把MySQL研究得特别深当然很好,但你能研究到多深首先是个问题。其次,这个时代光会MySQL也不够用了,还需要了解分布式计算和云计算,停留在原先那个深度上显然是不够的。如果你早知道Hadoop是下一个时代的数据计算框架,就应该把精力花在新时代的事物上。当然想把Hadoop研究得深,也离不开广度,例如你需要知道如何把一个算法切成所谓的MapReduce计算方式。反正在我看来,不能一味研究深度,必须得广广深深地往前走。

我自己一直不太敢谈深度,因为始终觉得人外有人。我会的这点东西很皮毛,所谓深度也就是做了多年技术,对于如何写出好的代码,和如何让一堆工程师一块儿写出好的代码这件事,有浅浅的研究,就算是现在的小优势吧。


技术人攻略访谈是关于技术人生活和成长的系列访问,由独立媒体人Gracia创立和维护。报道内容以“人”为核心,通过技术人的故事传递技术梦想;同时以小见大,见证技术的发展和行业的变迁。在这个前所未有的变革时代下,我们的眼光将投向有关:创造力、好奇心、冒险精神,这样一些长期被忽略的美好品质上。相信通过这样一群心怀梦想,并且正脚踏实地在改变世界的技术人,这些美好的东西将重新获得珍视。

联系方式 [email protected]
微博: @技术人攻略
订阅:微信搜“技术人攻略”或“dev-levelup”


感谢SegmentFault提供博客专栏及推广支持。
感谢迅达云成提供云主机及技术支持。

你可能感兴趣的:(github,git,技术人攻略)