入職半年後的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瀏覽器電腦版技術團隊在技術規範的真正落地方面也經歷了一定的過程，這是後一篇文章我們將一同回顧的內容。
作者微博：@至簡李雲