百度技術沙龍第 56 期 代碼重構與靈活交付

本文做者：HelloDeveloper

2014 年 11 月 15 日，由@百度主辦、@InfoQ負責策劃組織和實施的第 56 期百度技術沙龍活動上，來自的百度資深敏捷技術教練馬波、馮上以及資深敏捷教練蔡曉鷗，敏捷教練、軟件開發顧問申健這四位老師給你們分享了代碼重構以及靈活快速交付的故事。其中，馬波和馮上以對口相聲的方式參與本次分享，看點十足。本文將對「 網頁搜索核心模塊架構重構」、 「 商業變現創業產品快速交付的故事」、「銀行中的跨國研發團隊如何快速交付」這三個主題分享作下簡單的回顧，同時提供相關資料的下載。

 

主題一：網頁搜索核心模塊架構重構（下載講稿）

 

重構的是什麼？

 

首先來了解一下百度要重構的東西是什麼。馮上和馬波提到：它簡稱 C 模塊，是百度搜索引擎誕生以來核心的模塊。前先後後有九年的歷史，每一年幾乎有兩百名工程師在上面修修補補。是各類服務搜索的結果聚集點，它跟全部的模塊幾乎都有交互。因此也致使它的邏輯很是複雜。

 

它還有一個比較顯著的特色，就是開發很是密集，最近一年半有 206 我的貢獻過代碼，它處在快速開發的模塊，這種模塊咱們說要改變軟件的代碼結構有兩種方法，一種方法是乾脆扔掉從新寫，另一種方法是慢慢重構，這種模塊在這種開發的密度下不可能說從新扔掉另起爐竈，由於它在不停的迭代。因此最終採起的是一個漸進的過程，即真正重構的過程。

 

重構的項目背景

 

你們知道重構是在不改變產品功能的前提下，改變它內部的設計。百度最近幾年來也在逐漸的沿用工做人才，他們有很好的意識，這種部門和工程效率部進行頭腦風暴，咱們發現有不少狀況，八次是有六次是代碼邏輯錯誤，是由於寫差了，這樣把內部的質量問題曝露成外部的質量問題。

 

好比說這個模塊是 C++ 和 C 語言混的模塊，內存、指針這樣的問題，不少錯誤是由於代碼，固然業務邏輯自己不復雜，可是在問題本質複雜程度之上，重構的目的就是把它的隨意性下降到業務自己就能夠了。

項目成果展現

馮上提到：「上圖是咱們前幾個月作的東西，下面咱們會逐漸根據分析交互這部分的重構，講講具體是怎麼作的。咱們只改了其中 1/4 到 1/5 的代碼。還移除了不少無用的代碼。指導思想就是小步快跑、演進式設計、SOLID 原則。實現細節就是設計層面、編碼層面、工具層面，咱們在重構的時候也不知道它的理論模型是什麼樣的，看代碼已經看不到它的運行模型，因此沒有一個大的架構設計的過程，直接進到代碼裏面。好比說直接放到該放的類裏面，這樣慢慢的它的架構反而會清晰起來。」

在設計層面上，如何經過演進的過程使架構由混亂變成清晰。主要是作好詞性分析，詞性分析模塊的交互，咱們把這部分功能單獨提出來作了一個單獨的類。作兩種通訊平臺進行通訊，把原來的代碼揉在一塊兒，通訊平臺 A 一個類，通訊平臺 B 的用另外一個類，原來的類幹掉了。在這個過程中，兩個通訊平臺的行爲很是像，等數據包回來之後，這部分代碼和概念徹底是重用的。

還有一部分，在看代碼的過程當中，你會發現規定很是複雜的函數在各個階段都出現過。由於有同步查、異步查的，還有分階段查的。經過不斷的運用代碼的方法，抽出單獨的類，而後把他們放進去，通過這個過程以後，你會發現的很複雜的邏輯會變成一個很簡單的東西。

在重構的過程當中很依賴自動化的測試，若是沒有自動化測試很容易出錯誤，一開始咱們現有的測試是很慢的，大概跑一次到邊緣和單測進行完須要三十分鐘左右，對於咱們成天想運行不少次重構根本是沒法接受的。因此咱們第一件事情不只僅代碼的重構，還要幫他們升級測試工具，怎麼樣用一些工具和方法提升單測運行時間。咱們經過各類不一樣的手段大概提升到四分鐘就能夠跑完，這樣咱們能夠快速得到反饋。

另外，還增長了質量監控，包括代碼的複雜度和重複度，由於這個事情是要持續關注的，爲了防止代碼腐化的太快、太嚴重，之後也要關注。咱們想讓產品線的同窗更多的用集成開發，尤爲是作代碼搬移，若是你不用這個是很是痛苦的。

主題二：商業變現創業產品快速交付的故事

蔡曉鷗首先介紹了鳳巢的背景，隨着 4G 時代的到來，視頻廣告在手機上播放是很常見的，百度也在嘗試這種新的方式，在愛奇藝和百度視頻上投放廣告，依託的是鳳巢的廣告主，如今上線已經有三個月時間了，積累的廣告主用戶已經超過了十萬，收入天天是三百萬左右。據蔡曉鷗介紹這個項目挑戰比較大，是跨團隊項目，橫跨三個事業部，內外部依賴是 15 個，還要串聯一個子公司。這種創意產品在百度是很是少見的，初期開發的人數是 2500 人左右，時間比較緊，變動頻繁。

首先分析一下研發模型，一共分三個子團隊，第一個團隊是業務端作的是給廣告主用的系統，這個系統廣告主會在上面制定一些廣告的投放策略和性價。第二個是檢索端，檢索端是要匹配的用戶，哪些用戶是什麼 ID，這些 ID 跟大數據進行匹配，分析用戶的行爲，給他分配想看的廣告。看看具體是怎麼操做的。

如圖，把檢索當中的業務端要作的事情拆分紅 Story，一邊是業務端，另外一邊是檢索端。綠色表明之前端爲主的開發，右邊這個內部的依賴。找出 Story 之後，根據這些 story，把內部和外部的依賴一塊兒找出來，排出關鍵路徑和總體的項目計劃，制定合理測試方案。

以後，蔡曉鷗介紹了百度的研發工具鏈和 CI 的流水線，作集體的迴歸測試，部署測試環境。若是編譯或者單測失敗了，就在這個上面作了 API 測試，它會進入到下一個位置。剩下的就是在百度交付經理常規的工做，總體進度的推動。

主題三：銀行中的跨國研發團隊如何快速交付

區別於互聯網企業，銀行中的跨國研發團隊快速交付又是什麼樣的？申健提到：

首先是要統一產品體驗。你們知道，任何一家銀行面臨的市場都是不一樣的國家，每一個國家有本身的法律法規、業務情況等，致使帶來很大的維護性問題，而且不一樣團隊之間要進行交叉協做就很困難。

當時咱們的作法是引入靈活性，同時要兼顧可以定期的進行交付，之間作一個取捨。以後下降已有項目的維護成本，在軟件開發階段，你所投入的成本只是一部分，更大的成本在後面在維護階段，可是咱們每每作計劃的時候有意或者是無心的忽略了這點。

主要是如下三個策略來完成整個快速交付的過程：

第一個策略是涌現式設計，涌現是大天然裏廣泛存在的一種現象，不要像傳統同樣預先的定義一些流程，而是不斷的在當下的狀況下，涌現出新的你可能想不到的狀況和場景、作法，爲了下一個迭代你能作的更好，你可以進化。

第二個是基於主幹的開發，主幹上面隨時能夠進行部署和交付，這是咱們的方向和策略。今後沒有項目的分支，只有我的臨時的分支，咱們將盡快的提交到主分支上。這是一個很重要的策略，須要進行溝通和配合。

第三個叫持續集成，首先有靜態的語法檢查，咱們提取不一樣模塊之間的代碼，咱們淺淡產品作的不是簡單的手機界面，也是單頁面的 Web APP，你打開手機網頁之後一次性幾乎把全部的資源加載好了，不一樣的頁碼跳轉是不會進行刷新的，這是咱們在技術上進行的嘗試。由於前段的須要壓縮，進行一些代碼的混淆，防止被認錯代碼。

最後，申健總結到：咱們經過三大部分策略、架構和團隊，咱們最後達到效果是顯而易見的。須要改的代碼越少，交付速度越高。經過不斷的重構和調整，每次加新的項目越多，收益越大，須要改的代碼也越少。敏捷就是這樣迭代不斷添加的過程，爲了保證新的改動不影響前面已經好的功能，你的單元測試持續集成必定要跟上。

圓桌討論環節：

爲了促進參會者與咱們每期的嘉賓以及講師近距離交流，深刻探討在演講過程當中的疑問，本次活動設置了圓桌討論環節。在此環節中，在重構、交付、敏捷方法論、團隊建設等方面的探討比較多，四位老師分別對參會者提出的問題給出了詳細的解答。

會後，一些參會者也經過微信分享了他們的參會感覺：

@雷魁：敏捷方法簡單，如何讓團隊真正敏捷起來纔是最關鍵的。

@建生：重構就是儘可能解耦，產品的快捷交付就須要迴歸小團隊，模糊各模塊團隊的職責，重在溝通。

@灰太狼：任何一個團隊都須要「打雞血」的熱情。尤爲一種「正能量的雞血」，可以提升工做效率，激發你們熱情，團隊全員工做目標明確，充實而且知足。

@倪建龍：剛剛查百度，的確有 ember js 剛剛看屏幕代碼，我覺得是 angularjs，感受挺像的，學習應該是免費的，商用好像是要付費的。

原文連接地址：https://developer.baidu.com/topic/show/290166