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

文：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提供博客专栏及推广支持。
感谢迅达云成提供云主机及技术支持。