以下系 Coding.net CTO 孫宇聰接受 InfoQ 採訪內容整理稿。

Q：首先請您先自我介紹一下。

A：我叫孫宇聰 07年畢業之後加入了 Google 中國，在 Google 中國做了一年半，又調動到 Google美國做了7年SRE，然後今年年初回來創業。 目前在 Coding.net 擔任 CTO。我在 Google 的主要工作是 SRE，但是同時非常關注如何提高程式設計師的生產力。Coding.net的一大重點就是極為關注開發者這個群體，關注如何提升他們的生產力，做更好的工具，更好的社群，來幫助開發者成長。我們最近還推出了 Coding 碼市，讓開發者用自己的知識和技能賺取真金白銀。

Q：SRE 在前面的採訪裡也聊了不少，今天的採訪想更多的聚焦在Coding開發團隊內部變革上。目前『碼市』這個團隊的主要情況是什麼樣的？

A：目前，碼市和 Coding主站最開始在公司內部是兩條不同的產品線，分別有各自的團隊。

國內一般的創業公司、也包括大公司，新產品上線都是靠組建一支『敢死隊』。做一個新事情需要一個新團隊，『碼市』這支敢死隊與眾不同的是，我們完全沒有招新的員工，全部是從 Coding 工具團隊裡選出來的老員工組建而成。事實證明這樣的選擇是非常好的，把之前團隊裡的成熟經驗和工具都帶到新的業務上去了，加速了起步，也避免了許多問題。

但是對許多公司來說，新專案的團隊一般會採用很多不同的技術，產生很多新的想法，逐漸和老團隊越走越遠，越來越難以融合，這在未來就可能會存在很大的問題。舉個例子來說吧，在編譯系統的選用上， java的話，可能是 Maven 或者 Gradle，以及一些第三方的系統，雖然在功能上不會有太大區別，但是在不同編譯系統裡得到的經驗和最佳實踐並不能有很好的相互遷移。老的系統不肯改變，新的系統又無法融合回舊的體系，陷入了一個死迴圈。

我在 Google 最大的體會是：Google整個公司只有一套開發環境和研發體系。每個工程師雖然做的是不同的業務，但是強制所有人都使用同一套研發體系。這套研發體系長遠看來極大的促進了公司整體業務的研發效率提升，利遠大與弊。

碼市團隊初期也遇到了類似的問題，團隊採用了新的 Java 編譯系統可能就不一樣，新的 JavaScript 的編譯體系，雖然每一個改動都很小， 合併起來就是天壤之別。

如果一個創業公司做不到統一開發環境和研發體系，那麼勢必會造成我們研發力量的分散。這就是為什麼有些公司事兒特別少但人特別多，因為每個人所作的事情都不通用。雖然你可能說我們公司用的都是 Java，但是這裡面的細節和問題太多了。

作為CTO，我的一大目標就是把要把這些問題扼殺於萌芽之中（笑）。

Q：的確是創業團隊裡的開發者更喜歡嘗試新的東西。

A：完全禁止創新也是不可能的。因為作為一個公司、團隊必須要嘗試新鮮的東西，不然難以進步。如果一個團隊老用舊的東西那他就領會不到外界的好處。比如我們在碼市專案試行過之後，逐漸將全部 Coding 專案從 maven 切換到了 Gradle，因為真的很好用。

我這裡要說的關鍵是，作為一個創業團隊，我們必須需要定時把各個業務組聚在一起，共同評論一下 Gradle 什麼樣，Maven 什麼樣， 我們整體應該往什麼方向發展。 舉一個例子，這就和像園丁打理花園一樣，你可以讓花隨便長，但到了一定時間一定要把長得不好的砍掉，選出其中一種，或者是有限的幾種一定要留住的。最終的決定其實並不重要，重要的是要有這樣一個決策的過程，以及強有力的執行。

初創團隊人員的調動是非常頻繁的，一個人的興趣點會轉變，公司計劃也會改變。你做的專案幾個星期之後就可能由別人來維護。 我們在公司強調所有人寫的程式碼都是公司的共同財產， 每個人都有義務共同維護這些程式碼。

作為 CTO 來說，我的工作就是抵住 CEO 的壓力。每週我們要安排一些產品上的事情，我們也要留出一段時間來做架構上的整理，改進，統一。我需要給程式設計師們留出時間，創造條件來做這些長遠的事情。 只要把程式設計師聚到一起，他們自然而然就會產生出很好的想法來，然後再把這些好的想法推廣出去。

我們需要做到的有一下幾點。

第一， 我們一定要統一，不能『淺嘗輒止』，半途而廢。

現在的很多技術、工具，基本上是『萬能的』，只有好不好用的區別，沒有能不能的區別。 所以當我們發現了一個好用的工具，就必須要把他用好。而且是在全部專案上用好。

第二，創業公司要有計劃的投入力量，推動技術革新。

新工具、新架構改進雛形有了之後，我們必須要留出一段時間來讓老專案和新專案一起去推進，把改革真正貫徹到底。一個團隊只有真正能做到不斷學習新東西，然後能將他們完全應用到自己的老系統上去，這才是一個健康的體系和研發環境。

如果做不到這一點，隨著產品線越來越多，你的工具越來越多，研發體系的複雜性越來越高，資源就難以流動，公司會遇到很大問題。Coding內部在推行同一套編譯系統，同一套程式碼的組織方式，還有一些最佳實踐，比如說好用的靜態分析工具。 讓大家隨時都處於同一個環境裡面，使用同一套語系交流。同時，Coding 經常組織團隊之間的成員流動與相互分享，進一步鼓勵溝通。

只有一個研發體系能夠做到這種程度，建立良好的溝通體系，才能夠讓大家勁往一處使。研發部門是一個技術公司的發動機。發動機必須要所有零件合力去推動整個發動機的運轉，而不是單獨的小零件自己運轉。

Q：之前您也提到說，Google在工具流程統一方面做的很好，但是這也是經歷了一個過程，在最初的時候早期的工作還是很有挑戰性的。

A：一個技術公司哪怕是 Google、Twitter、Facebook，也無法確定的知道哪個工具是最好的、最合適的。 首先公司不能限制住大家的創新，要讓工程師隨便去試，去做微創新。但是同時公司內需要有一股核心力量，不關心具體業務，只關心怎麼吸收大家的微創新，使之成為可以實現的目標，推廣到所有的專案裡去。程式設計師不能全是寫業務的，應該留出一些力量做架構的，有一些是做基礎開發的。哪怕只有一個人也比零要強很多。

Q：你覺得現在以 Coding 現在的規模，專門設定一個人專門給內部開發工具服務的，是不是太早了點?

A：小公司內的確很難， 現在 Coding 內部也做了一個百分之二十計劃，就是一週裡留出一天的時間是給程式設計師用來思考『如何把現在的東西做好』。創新是一個急不得的過程，平時公司裡也會有很多新想法、新吐槽， 缺少的是能把想法和吐槽轉化成真正目標和力量的人。那我們至少可以做到定期把大家聚起來，每個人出一點時間，一起討論出一個方案。

作為 CTO 和管理層，需要做的就是關鍵時刻推一把，找到一個合適的人在合適的時間去去推進架構的進步。

還回到花園的比喻上，公司是一個花園，園丁只能除草和施肥，在合適的地方施加壓力，在合適的地方 say no，這樣才能把花園搞得很好，你對花的生長是無法控制的。管理技術團隊也是一樣的道理，把大家聚在一起，給他們創造條件，讓他們往一個方向努力，這樣才會成功。

Q：那您現在考慮比較多的事情或者問題分享一下？

A：給工程師創造更好的環境，真正提高工程師的生產力，這也是我們關注的一個目標。比如我們上海的工具團隊做了很多提高程式設計師生產力的工具，哪些是我們真正能用到我們自己身上的。

比如我們現在搞了一個網頁上看程式碼的 CodeInsight 的產品。像 IDE 一樣可以在網頁上看到所有的變數之間的關係，操作的流程，程式碼的流程，還支援非常好用的搜尋。

我們所有創新工具都首先在要在公司內部推推行。其他的還包括程式碼評審工具， 我們自己每天都在用。Coding 所有的開發管理，所有程式碼全都放在 Coding 平臺上，這樣我們才能先於使用者知道哪個地方有問題，那個地方要優化。這個我覺得還是比較好的點。

注：文章獲得Coding官方授權釋出。