5月7日，「騰訊SNG & msup技術開放日」在深圳召開。壹佰案例採訪了一些與會講師，談談他們將在會上分享的內容。本次採訪的是騰訊雲平臺產品技術負責人陳子舜。
壹佰案例：首先想請您介紹一下您目前的工作以及您關注的領域
陳子舜：我目前在騰訊雲團隊，負責平臺產品線的管理工作，其中包括前端團隊、團隊的能力建設等工作。從技術角度來說，我現在更多關注前端的發展，包括前端的一些趨勢和未來潛在的新技術。
壹佰案例：前端曾經被誤解為「做網頁」、「切圖」的，但隨著前端技術不斷髮展，我們也可以看到前端技術是現在發展最快的技術之一，類似AngularJS、React等框架層出不窮。現在的前端開發從簡單的Web開發到Web富應用開發，您對這種前端技術的發展趨勢是怎麼看的？
陳子舜：我非常認同前端發展很快這個說法，但也要注意到前端技術的起步是相對比較晚的。從2004年穀歌出了Gmail提出Ajax開始，大家才意識到這個技術其實能解決很多問題，但是如果再往前看的話，終端的一些發展，包括整個計算機領域的發展，其實對客戶端的要求，這個路徑已經走了很長時間。
前端因為發展的比較晚，現在才走到“我要去做元件”，“我要去提出AngularJS”，“提出一些從前端Router”到“提出雙向繫結等方式”，包括像React提供了一種元件的管理方式。以上的這些說法實際上並不新鮮，在客戶端開發裡，這些概念一直都有，只是前端基本上是按照客戶端的發展路徑不斷快速的對齊現在的發展趨勢。現在如果要看前端以後能往什麼方向發展的話，我覺得更多可以參考客戶端發展的路徑。
壹佰案例：QQ空間的業務隨著網際網路的發展、使用者數的增長，經過幾次技術升級的過程，您能從前端的角度談談QQ空間這幾次升級背後的故事嗎？
陳子舜：
第一個階段是我剛剛接觸QQ空間的工作，這個階段很重要的工作是什麼呢？當時我們面臨十萬使用者同時線上的臺階，而且對我們後臺負載有很高的要求。所以在當時我們最主要的工作是：我們怎麼樣先扛住使用者快速增長的階段，能夠給後臺降低負載壓力。因為2006年的前端開發模式，就是後臺主頁面的方式，我們發現如果按照這個方式做，後臺壓力很大，而且當時的後臺也沒有現在那麼好的硬體條件。我們前端的團隊當時也只有三個人，我們就想各種各樣的辦法來幫助後臺減壓。
怎麼做呢？我們把一些邏輯程式碼提到前端來，剛好也有Ajax的一些技術可以去創新，我們可以用這種前端非同步的方式把很多東西移到前端來。同時我們也更多考慮怎麼去減少後臺的請求，比如說檔案合併、預載入等，實際上很多都是我們在當時的架構考慮到的事情。
當然還有後臺請求過多的問題存在，不僅僅是頁面請求，還包括後臺CGI過多，因為空間分很多模組：個人中心、部落格、留言、頭像等所有資訊都代表後面有相應的服務。
當時按架構去考慮我怎麼樣在後端部署一個統一的環境來配合後臺，做好這種按照標區類的方式知道哪一個模組資料更新然後去動態拉取。其實這種邏輯在當時的前端是有些過於「重」的，但這也是一個標誌性的，讓我們度過了2006-2007年使用者快速增長的階段。
第二個階段我們發現前端變得越來越重。那個時候前端的程式碼裡面揹負了很多歷史問題，所以我們一直沒有對它進行太多改動。後來當時我們決定花了很長時間對空間程式碼進行重寫，需要重寫的程式碼量在當時統計出來的數字是非常大的。
特別需要提到的是當時為了做到極致，減少請求，把很多邏輯層程式碼都拆分到很小的檔案裡面。所以在重構的過程中，我們也引入了一些模組化的管理方式。
坦白講，比現在的模組化要引入的更早，但比較遺憾的是我們沒有對外輸出這些工具。舉例來說，我們內部寫了一些工具怎麼把這個檔案拆分，把目錄變得更加合理；還有一些工具自動化去合併，進行程式壓縮；也採用了自動化的方式，能夠保證我們的程式碼管理和部署。我覺得第二個很重要的階段就是我們怎麼樣對程式碼進行模組化管理。
第三個階段是團隊變得更大，團隊規模從幾個人變成十幾個人的時候。那麼怎麼去做呢？這時候產品對前端的要求越來越高，需要你實現越來越多功能，而且跨團隊的配合也越來越多，在我總結起來應該經歷了一個叫技術規範化和標準化的過程。
在前面程式碼已經管理好了，模組已經做好了，那怎樣提升效率，怎樣讓程式碼提交之後不會產生很明顯的錯誤。
我們當時的使用者挑戰很多，比如瀏覽器相容不行，當時其實有很多瀏覽器可以使用，比如火狐、Chorme這些版本都出來了，我們在瀏覽器測試上花了很多功夫，但是實際上還是沒有達到要求。當時我們就在想，我們團隊得有一個標準元件，有一個標準的框架來解決瀏覽器的相容問題。
在當時的階段，市面上能寫的框架也不是很多，所以我們決定自己去寫。為什麼自己寫呢？因為騰訊還是有一種喜歡自己造輪子的心，所以後來我自己就給團隊做了一份這樣的標準框架，在內部我們把它稱之為QZFL，實現了規範化。
這個框架從1.0發展到2.0走了很長時間，也解決了大家在開發過程中的問題，例如我不需要再去關注一些常用前端元件的實現、一些功能的實現，只要關注業務邏輯就能好了。
在技術標準化方面我們引入了監控，引入監控後，我們可以對整個網路的環境以及前端的客戶有了掌握，通過監控我知道前端的效能是如何的，知道我每一個請求的返回成功率是怎樣的。監控發展到現在也擴充了很多新的維度，比如說我知道哪一個省份的使用者比較慢；哪一個運營商網路比較慢；現在慢的使用者大概的百分比是多少等等。
這些資料可以幫我們不斷提升整體空間的運營水平、運營能力。我覺得這是一個很重要的標誌，讓我們走到了一個工業化的程度。這是我覺得空間現在做得比較成熟的很標誌的一件事情。
壹佰案例：QQ空間相關的技術已經很成熟了，未來還會遇到哪些挑戰？
陳子舜：QQ空間現在相對穩定，我也很難判斷以後會遇到什麼樣的技術難點。我覺得真正的難點在於它能不能應對現在日益變化的使用者需求，很難說某一個技術難點可以算作難點。而是我覺得QQ空間更多要應對的是現在終端使用者習慣的變化，技術能不能及時更新，解決使用者的問題。我們做很多事情還是以產品的價值為導向，我們要考慮通過技術手段解決具體的產品問題。
空間現在相對來說成熟，也是給我們團隊一個很好的機會。因為客戶訪問量仍然非常大，也就是現在比較火的海量服務。海量服務的特點是你每做一件事情，你的判斷都會影響大量使用者的使用。所以對程式設計師有很高的要求，每一件事都要考慮得非常清楚才可以去驗證實施。
其實QQ空間走到現在，還在做很多很前沿的嘗試。比如說希望嘗試HTTP2，空間的監控除了我們之前講的這種地區效能、運營商效能的監控以外，自己本身的資料染色、資料採集等等這些能力其實也做得越來越深入了，同時空間的前端元件從瀏覽器到接入層都是一整套完整的解決方案，這是QQ空間成熟的表現。
壹佰案例：前端的工作中優化是非常重要的一個模組，在一些論壇上也會對優化有很多的爭論，前不久就有使用者在知乎上就QQ空間開啟首頁就載入100+的JS提出問題，在這個優化標準的問題上您怎麼看，會不會以數字去衡量這些標準？
陳子舜：其實大家追求極致優化目標的衡量標準是唯一的，但是方案其實會隨著業務而產生多樣化的方案選擇。其實空間一直以來都在做優化，我們對極致的做法可能和很多人的常見的理解是不太一樣。
我們更喜歡不斷嘗試一些新方式，提出假設。我覺得前端的優化方式，都有一定的時效性和適用性。不見得說載入一百多個檔案就是好或壞,當然我們也不否認現在載入一百多個檔案確實不見得很好，可能是團隊管理，或一些其他技術以外的原因。而最後我們其實都是需要拿出的資料衡量。
例如：哪怕真的載入了100個檔案，有沒有想過：其實這100個檔案也許並沒有使使用者開啟的頁面變得很慢，而相反有辦法可以讓他感覺很快的？如果100多個檔案並不是在你首屏顯示的時候載入的，支撐首屏檔案做好控制，其他都走了非同步請求，檔案多也不見得對你的業務有太大影響。
所以我們的判斷在於使用者看到的效能如何，他用這個功能的時候能不能快速獲得想要的東西，這一切都是基於我們有可靠的資料分析後進行論證的。不斷提出假設，設計方案，更有針對性的優化某一些地方，針對使用者常見的一些問題，拿出去論證、驗證，然後採用或推翻之前的假設。
也許你會覺得載入了100個檔案有問題，但是從我們這邊的資料看，可能這並不會真正的影響使用者體驗。簡單來說，好比我們之前一直在說一些優化，要進行合併。經過幾次架構升級，我們發現有一些檔案我們把它合了又拆，拆了又合，合了又拆。這是因為我們隨著客戶的網路、硬體的變化，一直在進行調整。沒有一個最終標準可以說按照這個標準就可以做到一勞永逸的優化。
壹佰案例：提到Web優化，有很多公司提出過一些黃金法則，例如Yahoo，您如何看待這些法則，騰訊內部有沒有總結過類似的東西？
陳子舜：我們在技術總結方面的角度可能和其他公司不太一樣。我之前也講了一些優化的原則，我們的優化理念其實是類似國外「增長黑客」的理念，就是提出假設，設計方案，分析資料，驗證，推翻假設的過程。
我們覺得標準的東西不見得能夠通用，所以我們也沒有對外推出一些黃金標準。舉例來說Facebook也沒有對外提供標準，在給我們分享Bigpipe的時候分享者最後說了一句話，“我現在做的優化可能也只適合Facebook用，不見得適合大家”。
在我看來，黃金法則是隻告訴做法，但是並沒有告訴大家為什麼這樣思考為什麼要用這些做法，而現在雅虎很多的優化理論會有一些不合適的地方。甚至說的更直接一點，如果HTTP/2有一天火了，基本上這個雅虎的優化黃金法則就廢掉了，那你還要去用嗎？
所以優化是不斷演進的，我剛剛也講到，前端優化是有一定的時效性和適用性的。這樣就對前端開發有更高要求，一定是一個懂思考的程式設計師，才能提出更多的假設，並知道怎麼去論證。
所以，在騰訊我們不會看誰用了什麼法則而去判斷這個人能不能達到高階工程師的程度，而是看他的思考過程、思考邏輯，在解決這個問題的時候，你的思考邏輯是不是符合了這樣的方式，你找到了創新點，更漂亮地解決了一個具體的效能優化的問題。
壹佰案例：前端效能優化對普通使用者來說其實就是他開啟這個網頁更快了，但實際上在這個快背後是有很多可以做的技術工作。
陳子舜：沒錯，我們的效能優化目標是什麼？剛剛講得很清楚就是為了快。而快的目標是什麼？比如我的頁面開啟時間是1秒鐘，我們為這1秒鐘開啟花了很多工夫，不僅是前端壓縮，不僅是前端檔案合併，我會採用一些cache，我在業務用的一些網路延遲的手段、技術去讓網頁開啟的更快。其實這裡面前端考慮了非常多的問題。
另外隨著發展，現在前端越來越重，對使用者的CPU是不是一個消耗，對CPU的把控是不是有一個方法？我監控CPU的即時情況，能否保證首屏渲染的內容優先獲得CPU資源，一些重資源可以延遲渲染，不要影響使用者的開啟，所以我們也嘗試去通過對CPU資源的控制來提升效能。
另外也在思考在渲染方面我們是不是可以做得更深，我們要去研究瀏覽器的核心，考慮渲染方式，包括和我們的X5團隊、瀏覽器團隊也有很多交流。你會發現整個前端優化到最後，更多在於怎麼能發現問題，包括推動技術環節的各個角色去解決大部分的事情。
然而現在很多前端開發，大多數認為只要運用了某某原則、某某法則就完成了效能優化這件事情。但是他沒有想到，在整個頁面開啟的流程下面，會有很多基礎環節。包括頁面開啟的JS問題，頁面的請求，後端的效能，瀏覽器發生什麼事情，都有可能成為你的優化點。效能優化其實是一個持續的技術運營。
最難的是，你怎麼從各個環節發現可能存在的一些優化，提出假設之後，帶領團隊跟大家一起，把這種優化問題解決掉，這是程式工程師經常做的事情。
壹佰案例：提到帶領團隊，您經歷了從3個人到幾十個人的團隊演變過程，也成了一個管理者，團隊由小變大的過程中有沒有一些好的管理經驗分享給大家。
陳子舜：我帶領了很多團隊，在雲之前我帶的基本上都是新團隊，我剛剛過去就是幾個人，人少的時候時候我們先想辦法扛住業務的需要。
接下來團隊規模稍微大一些，我們需要建設一些管理的部分，來幫助這個團隊有效運轉，怎樣管理工作流程、開發模式，包括團隊之間合作的方式、流程的建設等。
到團隊規模再大一些，要求再高一些，就看你對團隊提出的標準。比如說程式碼規範、工程化管理，有更好的管理手段和工具引入進來，幫助團隊更有效的完成目標。
我覺得這是整個管理的過程，就好像我們管理方法中一個團隊的形成階段和磨合階段，以及團隊自身的規範期階段，最後產生團隊的績效，基本上都是按照這樣的思考方式去做。
壹佰案例：您的團隊中肯定有不少新人，隨著前端的火熱，也有不少人想去做前端，對於這些新人朋友，作為一個十年經驗的前端前輩，有什麼建議給他們？
陳子舜：前端其實和以前一樣是很容易入門的一個技術，但這個技術的挑戰也是太容易入門了，導致很多不是程式設計師的人過來做前端。要是真正喜歡做前端，想成為一個合格的前端開發，首先要是一個合格的程式設計師，而好的程式設計師是有一些要求的：
首先是計算機基礎，掌握一些網路演算法，對程式設計師來說這是根基，無論你是前端也好，還是後臺也好，這些都是很重要的，這是計算機基礎能力。
第二，程式設計師在編碼過程當中是不斷挑戰新問題、不斷提升程式碼的。同時好的程式設計師不會給後輩留下坑，他會考慮程式碼的可適用性，這種通用素質他會想得很好。
第三，作為程式設計師應該有嚴謹的思維邏輯。做任何事情、任何決策都需要資料論證，不會去猜測也不會輕易相信外界的一些黃金法則或建議。程式設計師懂得通過一個問題進行逆向思考，為什麼會提出這樣一個問題，一般都會有這樣一種很叛逆的想法。
另外，程式設計師對新技術要保持好奇心，但不應停留在我用了哪些新技術，而是要思考為什麼這個新技術會這麼設計，最終解決什麼問題，我覺得好的程式設計師在這方面會想得非常多。
在這些問題上，如果覺得自己都可以有這樣的想法之後，你再去前端領域，再去前端做更多事，那你是一個好的前端程式設計師，而不僅僅是一個簡單的前端開發的角色。
壹佰案例：在從新人成長為管理者的過程中，特別是經歷過很多不同的業務，您是如何在快變的環境下學習並迅速融入新業務的？
陳子舜：我其實在騰訊做了很多業務，從QQ空間到做增值產品到現在在做雲，在這個過程中我也在不斷學習。在做任何業務之前，我首先要了解這一塊業務是做什麼的，這一塊業務需要我的技術有什麼樣的變化。
從PC到手機終端的轉變過程中，那我們就說我們要去擁抱H5，擁抱類似的開發能力，讓自己也可以學習這一方面的知識，保證自己能夠達到業務要求，可以幫助業務解決問題。
現在做雲之後，發現做雲對狹義的前端（只寫JS）要求不像QQ空間那麼高，反而對程式設計師思維邏輯，以及全棧的要求會更高，因為你首先要重新認識雲的業務，重新理解業務對應的使用者是誰，雲的使用者其實對應的是廣大開發者；那廣大開發者需要獲得你什麼樣的幫助，你的產品可以給他什麼樣的支援，你怎麼樣做得更好。
然後就會思考我這個團隊現在的一些技能能不能滿足，我的團隊需要做出變化，能夠嘗試更多，甚至是站在更廣的層面思考這些開發者他們會遇到什麼樣的困難。
所以我這個團隊基本上轉變為全棧工程師的角色。到雲之後，我們需要了解更全面的知識點。我們就要把自己打造成一個全棧工程師，從前端JS到後臺NodeJS的能力，包括網路各個方面的東西，都要有很全面的把握，你打造出來的產品才可以解決更多客戶的問題。
我覺得在業務上我的學習方法，都是從業務的客戶需求出發，去考慮我的技術應該怎麼做出調整和轉型。
壹佰案例：騰訊如何看待前端，從公司層面會不會為大家制定能力模型？
陳子舜：我剛好是騰訊前端通道的負責人，其實通道的標準在去年我們也更新了一版，最早的晉升通道還是聚焦在前端JS這方面。你怎麼解決問題，怎麼做到效能優化，怎麼去做好業務的可持續運營，這些都是前端通道的要求。但是因為市場發展很快，我們也做了一些拆分，拆分成什麼樣呢？
第一，前端的遊戲方向。遊戲的偏重在於要有更快的學習能力、學習要求，因為遊戲技術變化也是非常快的，有很多新的遊戲框架和引擎，包括H5本身也有很多遊戲方案，你能不能快速學習。遊戲還有一些新的要求，比如對安全的要求，因為會有很多人在寫外掛，所以安全性的要求也是這個方向要考察的部分。
第二，前端的終端方向。對這個方向的要求會跟普通的前端開發不太一樣，因為它得跨界，首先要對H5的能力有所瞭解，還要了解一些Native終端的知識。這樣可以更好的解決使用者的問題，所以都會有一些偏重。第三，全棧工程師，我們內部叫全端工程師，這個就是說，我們把Node.js和PHP這部分放進來了。我們為什麼認為這個屬於前端領域呢？因為從使用者訪問頁面的「最後一公里」來看，使用者開啟瀏覽器到瀏覽器頁面輸出內容，這些事情都應該是由前端來覆蓋的。輸出頁面的技術，我們通常叫接入層，或者叫接入web服務，接入web服務這方面我們在前端有一定的話語權，並且能夠可控，我能夠在上面開發我們的業務，這樣做也可以減少我們和後臺開發協同的成本。
同時我們在做新的優化，包括業務邏輯上更有可控性，而不像以前在空間的時候，比如說我們要做一個優化，要push後臺其實是很難的事情，因為大家節奏可能會不一致，而且他也不一定理解你為什麼要這樣做。所以我們就提出了第三個叫做全棧工程師，這也是行業比較流行的概念。
第四，騰訊有一個更加特殊的領域叫體驗工程師，也是一個專業化的前端團隊。所以目前我們在通道里面分了四個方向，來覆蓋整個公司全端團隊他們所做的工作要求。而每一個方向也都由高階工程師制定的新的具體的要求，幫助大家不斷成長，跟上行業對自己能力的要求。
壹佰案例：您對全棧如何看？
陳子舜：對全棧工程師我是這麼看的，還是回到程式設計師的問題來講，程式設計師不應該是一個挑活兒的角色，很多技術都該感興趣。如果認為說多學幾個語言、有一定的跨界就叫全棧工程師，那其實可能對全棧的理解就窄化了。
一個真正好的全棧工程師的概念是包括對覆蓋的技術、對業務的理解、對各個角色的理解都應該有非常全面的認識。對全棧工程師來講，他最大的特質是說他能夠接受變化，遇到變化的時候，能夠快速轉變，可以解決具體問題，當然也要有一定的深度，這才是一個比較好的全棧。
從我本身來說，我自己雖然也說全棧，各種技術我都接觸過，包括後臺，包括Java，基本上都研究過一遍，當然我不能說所有的方面都有很深的瞭解，但是有一件事情我是能夠深入瞭解的，其他事情你讓我去做我也能夠去完成，基本上就是適應性很強的一個程式設計師。
大家都知道國外的知名IT公司，都喜歡招全棧工程師，簡單來說就是程式設計師不應該把某一個語言把自己框死，其實這個是現在在國內很多程式設計師很可怕的一個想法，大家把語言的level看的太高了，其實把語言作為一個工具，把自己從用這個工具的角色裡面跳出來，讓自己可以接觸擁抱這個行業的變化，讓自己在思路上能夠卻開啟更多。
壹佰案例：React背後是Facebook，AngularJs背後是谷歌，似乎還沒有很強的中國力量參與其中。您對中國未來前端發展，包括一些開源的力量，是怎麼看的，未來有沒有可能有中國的公司去做類似的事情？
陳子舜：沒有能拿出一個框架來並不是中國的程式設計師能力不夠，而是說是否有足夠的管理機制、管理辦法鼓勵這些程式設計師，可以讓他們不斷提升，或者說不斷投入在這個事情上面。
因為在我看來，國內很多的網際網路公司還是在積極進取開疆擴土的階段，無論是業務導向或運營導向都會要求程式設計師要去解決大量的眼前的問題。其實一個好的開源元件不僅僅是你做出來了，最重要的是你能不能把社群維護起來，能不能把大家對這個元件的熱度維護起來。不能夠持續地輸出更新、保持迭代，這個是大部分國內的前端的框架和元件遇到的困難。
如果說這個問題可以解決，我相信國內還是會拿出一些蠻出色框架，讓更多人去使用。據我所知，國內很多原來本身在一起給公司提供前端標準的團隊慢慢也拆散了，我也希望有一天國內的公司可以做出一些調整，能夠專門有一個團隊，為了行業去提供和設計這樣的一些技術能力。
但國內可能還不如國外有這種技術的氛圍。我問過React的團隊，我問他為什麼Facebook願意鼓勵他們做這樣的事，他們也講到了一些點我覺得很有意思：因為開源React可以解決他們招聘的問題。
壹佰案例：通過開源React去解決招聘問題？
陳子舜：React在Facebook內部也醞釀漫長時間，甚至有一度停止更新，後來也是有志的程式設計師拿出來重新改良後推出。其實通過這個案例我們就可以看出做開源框架需要長期的投入。你做的React好用，讓更多開發者去用，這些開發者肯定都懂得React，招聘後也減少人才培養的成本，同時很多人也會慕名而來，大家會抱著這樣的想法，原來React是Facebook推出的，那我願意去加入這個團隊和他們一起工作。這也形成了一定的人才招聘的氛圍。
本文轉自“壹佰案例”公眾號，原文連結