清风：豆瓣神组小组长，日式萌神程序员
文：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”