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

文：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创立和维护。报道内容以“人”为核心，通过技术人的故事传递技术梦想；同时以小见大，见证技术的发展和行业的变迁。在这个前所未有的变革时代下，我们的眼光将投向有关：创造力、好奇心、冒险精神，这样一些长期被忽略的美好品质上。相信通过这样一群心怀梦想，并且正脚踏实地在改变世界的技术人，这些美好的东西将重新获得珍视。

联系方式 gracia@devlevelup.com
微博: @技术人攻略
订阅：微信搜“技术人攻略”或“dev-levelup”

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