他是2013年QCon北京云計算專題的出品人，也是2014年QCon北京移動應用專題的出品人。他的團隊往下做到云計算基礎架構，往上做到客戶端。他本人從80年代末起接觸編程，在大數據處理、云計算、以及分布式系統等方面都玩過一圈。他是蔣煒航，網易技術總監，目前全面負責有道云筆記業務。

在這樣一個團隊中，后端和前端團隊在同一個產品上工作，有緊密的協作關系。但是，底層的軟件研發和應用層的軟件研發畢竟有很大的區別，他們在代碼提 交和管理模式、測試機制、代碼的交付周期、反饋和監控體系方面都有怎樣的異同？在本次采訪中，蔣煒航博士會介紹有道云筆記團隊的一些實踐。

InfoQ：您在去年QCon北京出品云計算專題，今年則出品移動App的專題。這也對應了有道云筆記在技術上的一個特點，就是從底層到客戶端都是你們自己來研發、維護、運營的。能先簡單介紹一下跟有道云筆記相關的技術團隊都有哪些，各自負責哪些方面嗎？

蔣煒航：我們底層有基礎架構組，這個組在云筆記業務之前就建立了，服務的對象不單單是云筆記，還服務有道的很多 業務。這個組也在我的團隊，做的東西跟Hadoop（HDFS、HBase、MapReduce）這些差不多，是自己研發的一套系統。底層提供的東西比較 基礎，只是存儲和計算服務，對所有業務通用，本身不包含業務邏輯。

業務邏輯的開發都在服務器端的團隊，這個團隊專門是負責云筆記的服務器端的，負責處理同步、多版本、提供API等服務。

客戶端包括PC、Mac、iOS、Android、Windows Phone的客戶端，以及web端和瀏覽器插件。基本上每一層的團隊都是幾個人來做，不是很多。

此外我們還有個精干的研究團隊，這個部門做的是一些三到六個月才有成績的東西。方向主要是應用研究，研究的目標不是發論文，而是把成熟的技術做到產 品中。比如編輯器，我們需要做跨平臺的編輯器，過去大家比較熟悉的就是Office和Google Doc，而以前很多Web based的編輯器并不適合跨平臺終端的需求。我們一開始也是用Web編輯器做起來的，但是并不是很適合。我們也不可能像Office那樣用幾百個人去做 一個編輯器出來，所以研究部門做的事情就是，花一定的時間找到合適的方法來提升編輯器的體驗。提高跨平臺的體驗是一個很模糊的目標，不確定性很大，具體用 什么做法要很多研究和嘗試。這個團隊還研究一些NLP和手寫輸入方面的項目。

InfoQ：有些軟件產品的發展思路是求快，尤其在產品推出初期，要以最快的速度推出新的特性以驗證產品的可行性；有些軟件產品的 思路是求穩，尤其在產品積累了一定用戶量的時候，會更加關注軟件的穩定性、安全性，升級的時候不要對現有用戶造成負面影響。有道云筆記現在處于怎樣的階 段，是偏重求快還是求穩？

蔣煒航：做互聯網產品永遠是要快的。同時，云筆記是個人的信息、知識管理工具，穩定性非常重要。要快，同時也要堅守產品質量，我們必須要兩者兼顧。

可以這么說：我們的目標就是，***化高質量產品的輸出。我們無論做什么事，都要以優化它為目標來做。敏捷、測試、監控，都是很重要的手段，但相比之 下，清晰的目標才是更加重要的。比如，什么叫做快？新版本發布多了就是快嗎？引入新特性的頻率高就是快嗎？我覺得不是。新版本發布，可能會有很多bug； 新特性引入，可能是用戶根本不關心的，可能你80%的用戶從來都不會用到。所以這樣的快是沒有意義的。

我們對快的定義是，要讓有效的產品嘗試的速度盡量的快。你發一個新版本來測試，是否獲得了更多對用戶的理解？新功能是否讓用戶在某個場景下的需求得到更好的滿足？用戶是否更加活躍了？有效的快速是滿足業務目標的速度，這是通過不斷為用戶提供更合適的功能來實現的。

我們現在發布重要的版本，會先在內部做高保真原型，在內部試用，從內部非常快的得到有效的反饋。然后我們會做很多的小范圍用戶測試和AB測試，比如 在不同的渠道分發不同的軟件包，來驗證新的交互、新的功能，改掉原有的問題。另外我們還有一個很簡單的原則：我們客戶端覆蓋這么多的平臺，但是一個新功能 的引入可能先只在一個平臺上做，這樣我們可以很快通過用戶分析，了解用戶是否需要這個功能，確認有用了才在全平臺鋪開。否則，就不引入其他平臺，這樣其他 平臺可以有更多機會嘗試其他的東西。

在這樣的思路下，我們測試階段的服務器端也可以做的很簡單，比如我測試覆蓋就幾百幾千人，那就先用Node.js搭一個服務給他們用就好了，性能問題可以以后再考慮。很多時候，做面向三五個專家用戶（資深產品經理）的內測也已經足夠了。

做軟件開發不是做選擇題，要么選A要么選B。只要目標明確，具體用什么手段都可以的。

InfoQ：你們后端研發團隊和客戶端研發團隊在開發模式上的差異大么？

蔣煒航：本質上沒有任何差別，大家都是為了業務的發展。實際上，我們有很多好的移動端研發工程師是從服務器端轉 過去的。很多應屆畢業生是沒做過前端和移動端，他們一開始就是對服務器端感興趣。我們就會讓他先做服務器，其中一些人就會轉崗到客戶端去?；旧?，優秀的 工程師在哪里都是優秀的，所以我們內部鼓勵full stack工程師，可以從頭到尾把高保真原型做出來，包括前端的JS、iOS、Android App、后臺服務。我們所有的工程師都要有敏捷的思路，以及以用戶為中心的認同感，這些方面是一致的。

當然，因為前后端軟件的特性不同，肯定會有一些差異。比如，服務器端對性能更加敏感，所以會關注很多提高性能的手段。當然這些思路，客戶端也可以引 入。另一方面，敏捷在客戶端是比較常見的，因為客戶端是功能驅動開發，對交付速度要求更高。當然，服務器端也要有一定的敏捷思路，不能說要我提供十個接 口，我就要做倆月。我完全可以用一周時間，用一些現成的技術，比如MySQL，把這個接口先提供出來，讓客戶端的開發能夠用起來，之后再考慮性能問題，是 不是要移到并行文件系統上面去，等等。

總之，在規定的Sprint之內，我們一定要做出一個完整的版本。無論是客戶端工程師還是服務器端工程師，他們的工作質量都是很容易判斷的。

InfoQ：兩個團隊的交付周期是一樣的嗎？

蔣煒航：交付周期都是一樣的，我們的節奏是一個月，也就是每個月都會有新版本出來，只不過有些不對外發布。

我負責這個業務，具體來說我并不關心客戶端團隊是不是在滿負荷工作，或者服務器端團隊是不是在滿負荷工作，我關心的是我們在這個周期內，產品經理想要展現給用戶的價值是否高質量的完成了，是否能給用戶提供一個高質量的版本，這是最重要的。

InfoQ：兩個團隊的代碼提交方式、代碼review機制、測試機制是怎樣的？

蔣煒航：我們內部用SVN提交代碼，每個項目提交到各自的repo里面。代碼審查是結對review的方式。

測試方面，主要由工程師自己寫單元測試，交到自動化測試系統里去跑。我們有強制的測試覆蓋率的要求。當然，服務器端和客戶端跑的測試是不一樣的，服務器端需要做更多的壓力測試，而客戶端在自動測試外還要做很多功能測試。

InfoQ：在監控和反饋機制方面，兩個團隊又分別是如何去做的？

蔣煒航：服務器端主要是服務器健康狀態的監控。客戶端有我們自己寫的crash report機制，還有一套自己的BI系統，用于收集業務方面的指標。

整個產品的日志跟功能是一樣重要的，一起開發、測試。有健康的日志系統，才能了解用戶的使用情況。這套日志系統檢測的指標有幾百項，其中一些比較重 要的指標包括日活躍用戶量、各個功能的使用率、用戶滿意度等等。其中用戶滿意度是關鍵指標，也就是NPS（net promoter score），我們所有的產品中都有這個分數，這個分數體現了用戶對產品的喜愛度。

InfoQ：客戶端團隊相當于是底層團隊的客戶，這兩個團隊之間是如何進行溝通的？

蔣煒航：一個一個sprint來走。我們每個sprint先開客戶端的會議，事先跟server端溝通好，要做 什么功能，可能有哪些接口，之后就是非常自主的形式了。比如客戶端安排要做功能A，server端做接口A，那么這兩邊的人就會自己去溝通，討論API該 如何設計，協議如何做。

敏捷小組的特性就是自發性，我們沒有規定誰是誰的客戶，或者誰lead誰。我們就是設定了目標，分配任務到每個組，之后任何人都能驅動。比如很常見 的，客戶端說某個接口做的不對，會跟server端一起去改接口，不會說客戶端不管API的設計，給什么用什么，大家肯定是一起來設計的。因為我們的工程 師是full stack，所以這點是比較自然的。

另外，我們的產品、測試、運營也都跟研發團隊是坐在一起的，這幾個團隊之間的溝通都很多。我自己現在是60%在產品上，20%盯研發進度，20%在運營和市場上。