打造高質效的技術團隊 —— 醞釀篇

入職半年後的2013年6月份左右，淘寶瀏覽器團隊和搜索團隊被剝離出阿里巴巴集團，成爲阿里巴巴與UC優視所成立合資公司——廣州神馬移動信息技術有限公司——的主體。在合資公司正式成立以前，主管在一次與個人面談中告知「咱們得成爲一家小公司的一部分，且可能要從新基於Chromium的最新內核開發新的瀏覽器」（注：「新的瀏覽器」正是指如今的「UC瀏覽器電腦版」）。當聽到這一消息時我很是高興，由於看到這是一個可貴的團隊從新審視過去和甩掉歷史包袱的契機。在此次面談中，我回應主管「看來我得好好發揮一下」。也從此次談話開始，我非官方地成爲了開發團隊的軟件架構師。之因此說是「非官方」，由於我只是在心裏任命本身成爲了團隊的軟件架構師。

 

改變整個開發團隊各類亂相的第一步是讓工做有章可循，即制定開發活動的各方面規範。我在入職之初曾發起過《軟件開發指南》（後面簡稱「《指南》」）的編寫，初衷是試圖經過工做規範化去改善團隊的工做質量與效率，而此時要作的是全方位地充實其中的內容。

 

規範首先要立足於技術角度，指導團隊解決在開發活動中因不遵照Chromium架構而致使的各類混亂問題。在以前的淘寶瀏覽器時代，團隊對所擴展功能的代碼採用集中組織的方式（以下圖左邊所示例的那樣）。然而，這種組織方式存在兩大弊病：一，表面上工程師無需徹底掌握Chromium的架構就能開展工做，但也正因如此致使模塊間存在混亂的依賴和耦合關係；二，因爲沒有清晰的架構，工程師增長文件和目錄時徹底沒有指導思想，這進一步滋長了混亂。新規範要求將一個功能模塊採用「打散」的方式組織（以下圖右邊所示的那樣），而「打散」到什麼程度徹底以Chromium的架構爲參照，即要求擴展功能的代碼與Chromium的架構徹底吻合。儘管這一改變看似很小，但卻迫使工程師在平常工做中得先理解Chromium的架構，所帶來的積極影響卻極其深遠，由於它能完全杜絕大模塊的混亂問題！團隊中的小盤同窗有一次對我說「如今（按照規範）增長文件和目錄非常輕鬆」，而這一工做以前非常讓人糾結，那時你們能感覺到彆扭但殊不知如何解決。

規範還得從技術層面解決自有代碼與原生代碼的解耦問題。因爲咱們的產品是對Chromium開源項目的二次開發，須要經過良好的軟件設計解耦使得能快速跟進其發展步伐，以解決團隊長期遭受的內核升級之痛。在淘寶瀏覽器時代，因爲沒有明確的規範，以及檢查規範實施是否到位的手段，使得自有代碼與Chromium原生代碼難以明顯區分，致使在每次內核升級時得花大量的時間進行代碼合併，甚至對很多代碼進行重放。新規範要求在Chromium原生代碼中所變動的每一處都採用宏加以控制，其所達到的效果是咱們只在Chromium的原生代碼之上作加法。另外，宏在下次內核升級活動中起到了「燈塔」的做用（這是團隊的雷翼同窗作過3個內核版本升級後的切身體會）。新規範還從軟件設計層面多方位指導如何實現解耦。

 

顯然，《指南》中不可能規範開發活動中的每一處細節，這就須要整個開發團隊有更爲明確但抽象的開發策略以指導你們對所面臨的未加規範的內容進行決策。爲此，我在《指南》中明確「以快速跟進Chromium內核的發展」做爲整個開發團隊的開發策略。從用戶層面，這一策略使得他們能更早用上安全漏洞更少、性能更好的產品；從開發團隊層面，這使得咱們能經過快速跟進的方式，將內核升級的工做以小步快跑的形式推動。這一策略的制定一樣在未來產生了深遠的影響，它甚至引起了開發團隊與其餘團隊的一些思路碰撞，這是咱們後續篇章要涉及的內容。

 

除了規範層面，在進入UC瀏覽器時代之初，團隊在技術層面也積極儲備。雷翼與小盤同窗完成了git的部署並引導整個團隊從SVN轉向git；雷翼同窗完成了buildbot的部署，buildbot使得咱們能快速定位開發過程當中引入的問題和及時發現對Chromium原生代碼變動不符解耦規範的內容；小盤同窗則開始着力於更深層次的性能優化；另外幾位同窗與我一道將淘寶瀏覽器的一些模塊搬到了新的Chromium內核上，並對代碼結構根據《指南》的要求進行了優化。

 

即使開發團隊那時爲UC瀏覽器電腦版的開發準備工做開展得如火如荼，但管理層對後續開發究竟基於淘寶瀏覽器仍是最新的Chromium內核實施仍猶豫不決。基於淘寶瀏覽器開發的好處是項目時間更可控，但整個團隊得揹負以前的不少歷史包袱，且很難藉助此次開發新瀏覽器的機會卸去這些包袱；基於Chromium全新內核開發雖須要更多的開發時間，但這也是整個團隊從新塑造本身的一次大好機會，只是當時管理層對團隊可否抓住此次機會重塑並無十足的信心。在最後一次開發團隊內部開會討論最終的實施方案時，好幾位同窗與我一道力薦基於最新的Chromium內核實施，爲了說服你們採納這一方案我以「此次不一樣，由於有我在」這句話想給團隊帶去更足的信心，而很多同窗報以掌聲表達了本身的意願。

 

也就這樣，整個開發團隊醞釀好了抓住此次機會重塑本身！

 

至此，相信讀者所看到的更可能是技術因素，而沒有管理因素的影子（讀者會在未來的篇章中看到，請保持耐心）。對於中國的技術團隊來講，我堅信促使整個團隊改善的首要驅動力必定來自技術領域，只有採用以技術領域爲切入點逐步***到管理領域的方式，才更有可能讓團隊發生質的變化。緣由在於，很多工程師自然地將技術與管理作了明顯的割裂，這些人關注的焦點在於掌握更廣、更深的技術，對於管理能力並不大在乎，且對自我管理能力非常不覺得然。然而，真正專業的工程師也好、管理者也罷，很重要的一點倒是他須要具有良好的自我管理能力。自我管理能力的廣泛缺失，很好地解釋了中國的技術團隊爲何難以高效運做，也從某種程度上解釋了很多工程師單幹能夠但合做卻不行。

 

相信讀者在本身所呆過的團隊見過各類技術規範，但大多情形下這些規範被束之高閣。與之類似地，UC瀏覽器電腦版技術團隊在技術規範的真正落地方面也經歷了必定的過程，這是後一篇文章咱們將一同回顧的內容。

做者微博：@至簡李雲