技術人攻略訪談三十二| 清風：豆瓣神組小組長，日式萌神程序員

文：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提供博客專欄及推廣支持。
感謝迅達雲成提供雲主機及技術支持。