簡介：?數據中臺前端研發無不讓人厚重真實地感受到“唯一不變的是變化”。拿集團的數據資產服務平臺來說，業務上經過兩年的發展，已由單一的數據管理和使用平臺發展成了集團具有一定規模和影響力的全域數據要素交易所，而從前端技術側，僅從代碼提交報表就能明顯看到，今年的代碼提交量平均是去年的 2-3 倍，可見其業務擴張速度之快。

作者 | 杭歌
來源 | 阿里技術公眾號

一 背景

數據中臺前端研發無不讓人厚重真實地感受到“唯一不變的是變化”。拿集團的數據資產服務平臺來說，業務上經過兩年的發展，已由單一的數據管理和使用平臺發展成了集團具有一定規模和影響力的全域數據要素交易所，而從前端技術側，僅從代碼提交報表就能明顯看到，今年的代碼提交量平均是去年的 2-3 倍，可見其業務擴張速度之快。

代碼提交量暴漲的背后，是團隊、技術和研發過程的發展。研發團隊從最初的 2-3 人，發展到了如今約 10 人規模；項目的前端工程也經歷了從常規的 React+TypeScript+數據流架構，到支持多獨立業務模塊的 Monorepo 微前端形式，再到 Pro-Code 與搭建結合的開發模式；流程上也經歷過月級別的大迭代與周級別的敏捷開發，有過單人負責與多人協作開發，甚至與外包同學遠程跨業務領域廣泛協作，經歷了不少難題。

1 為什么要數據化運營？

遇到的困難中，今日且不談這些具體的難題，業務的增長帶來技術和團隊的種種變化，再平常不過了。不妨換個思路，跳出研究問題本身，先找一找問題產生的根本性原因：

• 覺得一天到晚都在處理代碼評審，為什么？是業務需求多，節奏快，還是開發者的習慣或研發流程節奏出現了問題？
• 代碼評審問題那么多，處理了兩三天還不斷有新的問題，為什么？是開發者代碼水平問題還是自己評審的方式存在不妥的地方？
• 一個開發同學同樣的問題每次總是出現，為什么？是業務邏輯本身限制還是編碼流程和規范培訓得不到位？

我們當然希望每個問題都能準確找到它們的根本原因，因此我們經常找開發同學尋求反饋，但反饋效果往往比較局限。例如，我不去問，對方不會反饋問題；我覺得不需要優化的點，對方覺得需要；我打算以某種方式解決某效率問題，但常常是解決得不徹底或者根本沒有解決。

這個問題的根本原因在于，我們都是站在自己的視角來審視問題，而沒有一個更高的俯視視角來幫助我們看清全局，甚至是洞察一些規律性、預測性的變化。越來越多的訴求指向了“數據化運營”這個概念。

2 明確目標

上面我們提到，希望通過研發效能的數據化運營思路，通過真實的研發效能數據來看清團隊的整體大盤和明細指標，就能從更高的位置審視團隊的業務研發，隱藏的問題就能夠在數據中暴露，問題的原因就能夠在數據中自現，從而使人更好地思考如何解決，更加準確定位到根本，最終使研發效能得到提升。

作為數據中臺前端團隊業務開發者與研發流程管控者中的一員，本次和大家分享在團隊中我們如何運用數據化運營的思路來管理研發流程與研發質量，達到提升研發效能的目標。

二 研發效能數據化運營全鏈路

1 設計指標

要提升研發效能，我們需要定義出關鍵的數據指標。通常的研發效能指標涵蓋了整個研發流程中的不同環節，相輔相成。如“代碼質量分（代碼 Lint 問題數）”“需求研發周期”“敏捷迭代交付周期”“研發活動效率”“發布耗時”等。

限于篇幅，本文以“研發活動效率”這一指標為研究對象，探討結合團隊實際情況，我們能做什么。

研發活動是團隊平常進行最多的事，映射到具體的研發流程，則是代碼 Commit 和提交代碼評審。評審人負責代碼評審的質量把控，并最終通過評審并合并代碼到主分支，一次“研發活動”即告捷。經過團隊大量實踐表明，最能影響研發活動效率的是代碼評審的提交頻率和處理時間。

首先，對開發者，代碼評審需要規約。我們規定以 1 天或 2 天為代碼評審提交周期，以每個 Aone 缺陷或需求為最小粒度，隔一段時間就提一個，否則會造成新開發代碼量的積壓，造成評審人壓力過大，若是問題較多，或是邏輯出現方向性問題，更難以控制項目進度和風險；相反，如果頻率過高，中途不斷打斷評審人正常的工作，也會對其造成困擾。

其次，對代碼評審人，也需要一定的約定。例如代碼評審提交過來，可能有些評審同學會忘記或暫時擱置，造成提交的代碼久久無人處理，與此同時開發同學又提交了新的業務代碼，就回到了上面提到的代碼積壓問題，造成評審阻塞的惡性循環。

聊到這兒，相信大家已經知道了團隊的痛點：在 5+ 業務領域，8+ 需求并行，加以外包協作的 10 人（正式同學）前端研發團隊中，我們明確代碼評審暴露的問題，但我們不知道量化出來具體是怎么樣的情況，到底耗時多久，也不知道是哪些開發同學或評審同學的節奏出現了異常，問題只有現象沒有切入點。因此我們走一個數據化運營的完整流程，來嘗試解決上述問題。

2 埋點上報

明確了要觀察的指標，下一步是對整個指標進行拆解，確定在研發流程中需要上報哪些數據。對“代碼評審處理時長和頻率”，我們可以分解出如下信息：

• 代碼評審提交時間
• 代碼評審通過時間
• 代碼提交人
• 代碼評審人
• 該輪代碼評審是否被合并
• 該輪代碼評審的輪次
• 其他必要的信息，如提交的評審屬于哪個分支，哪個需求，哪個項目等。

如何收集這些數據呢？

團隊研發效能工具簡介

得益于團隊的研發效能基建（見上圖），我們通過研發效能工具 DT-Hornet，實現了團隊研發流程管控的“大一統”。

• 在調用自定義 NPM Script 的“req”（需求管理，requirements manage）命令進行分支創建和維護時，能夠收集到分支和對應的需求相關信息，甚至讓開發者預先填好需求的聯調、提測、發布等時間節奏；

• 在調用“cr”（提交代碼評審，code review）命令提交代碼評審時，工具能夠通過開發者所在的分支自動識別到其對應需求并自動確認目標分支，自動收集 Commit 信息，觸發 Aone 相關提交邏輯，方便地創建代碼評審并發送釘釘通知到群；
• 在調用“pub”（發布，publish）命令時通過自動識別到的開發者和需求信息，自動發布準確的預發環境（團隊內是多套前端環境并存，互不干擾）。

CR命令層埋點邏輯

下面聊一些技術細節。當開發者提交 CR 時，經過如下步驟的自動化處理：

• 校驗工作區是否干凈，判斷當前分支有效性；
• 找到對應需求，確認目標分支；
• 訪問持久化數據，檢查是否有前置 CR（即，前一次 CR 未合并，本次有新的 Commit，提交后仍然是同一個CR）；

• 查找是否有未上報的已完成 CR 信息，并收集其中有用的信息并上報：

  • 在此過程中，會計算前一次 CR 的最新 Commit ID 是否已經包含在目標遠程分支的 Commit Log 集合中，若包含則表示代碼已合并，即 CR 已完成；
  • 若有已完成的 CR 信息，則從持久化 CR 信息中取得 CR 提交時間，從目標分支的 Commit Log 中取得代碼合并結點的提交時間作為代碼合并時間，即可作為準確的 CR 通過時間；

• 代碼檢查，自動合并目標分支代碼，若產生代碼沖突則報錯返回；
• 執行真正的提交 CR 邏輯，并將 CR 所有信息合在一起做數據上報和持久化存儲，后續釘釘通知到群；
• 最后對 CR Commit 進行打標，方便后續通過 Tag 找到 Commit ID。

監控平臺使用及技術層邏輯簡介

在上述 CR 提交與埋點邏輯的基礎上，借助集團監控平臺ARMS的能力（封裝了通用能力 Trace-SDK），我們能夠輕易地上報數據。

要使用監控平臺，需要在其中注冊一個應用，獲得一個 PID 唯一標識。在埋點上報邏輯中，在 Trace-SDK 實例化時傳入該 PID，埋點處調用其 log API 即可完成上報。如下代碼展示了效能工具內核如何調用 Trace-SDK 來聲明其通用埋點上報邏輯。

/** 效能工具內核類聲明（與埋點上報監控平臺相關的部分） */ class HornetCore {/** 監控單實例聲明 */private static traceInstance: TraceSdkType = null;/** HornetCore 監控初始化 */public static initTrace = (): void => {HornetCore.traceInstance = new TraceLiteSdk({ pid: '<研發效能工具PID>' });};/** 上報參數給監控平臺 */public static sendTraceLog = async (/*** 上報類型*/type: string,/*** 上報的參數*/params?: TraceLogParamType,): Promise<void> => {try {// 操作人工號const uid = DYNAMIC_NAMES.ADMIN_WORK_ID;// 操作人const c1 = DYNAMIC_NAMES.ADMIN_NAME;// 應用名const c2 = DYNAMIC_NAMES.PROJECT_NAME;// 分支名const c3 = DYNAMIC_NAMES.BRANCH_NAME;let c4: any;let c5: any;let c6: any;let c7: any;let c8: any;// 工具是否最新版const c9 = HornetCore.isLatestVersion.toString();// 工具內核版本號const c10 = HornetCore.version;switch (type) {case TRACE_LOG_TYPE.CR: {const { targetBranch, crAdmins, crAdminCnt, currentReqName, crSequence } = params || {};[c4, c5, c6, c7, c8] = [targetBranch, crAdmins, crAdminCnt, currentReqName, crSequence];break;}case TRACE_LOG_TYPE.CR_HANDLING: {const { targetBranch, currentReqName, crCount, crStartTime, crEndTime } = params || {};[c4, c5, c6, c7, c8] = [targetBranch, currentReqName, crCount, crStartTime, crEndTime];break;}default:[c4, c5, c6, c7, c8] = [null, null, null, null, null];}const logParams = { type, uid, c1, c2, c3, c4, c5, c6, c7, c8, c9, c10 };return HornetCore.traceInstance.log(logParams);} catch (e) {BasicMessage.error(`上報數據錯誤: ${SPLIT_VALUE.BREAK}${e}`);return Promise.reject();}}; }

如代碼所示，工具組織各個不同的 C 字段（自定義上報字段）來搭配不同的上報類型進行上報，在 CR 上報的場景中，需要兩種類型，CR 用來上報按“次”來計算的 CR 的詳細信息，而 CR_HANDLING 用來上報計算后的按“輪”來計算的 CR 信息，一“輪” CR 中可能包含多“次” CR。

在監控平臺側，對應地配置了上報類型和 C 字段的別名，方便后續的數據拉取和處理。如下圖所示。

埋點上報數據即發送請求。一般是請求服務端某個 1*1 像素的圖片，并在請求發送時帶上所有需要上報的信息。這里除了 CR 信息，還包括一些通用的系統層面的信息。

監控平臺接收到數據，將數據通過日志服務存儲到 HBase 集群，數據在 ARMS 平臺即可通過即席查詢獲取到。

3 數據處理

歸功于 ARMS 監控平臺，上述步驟已完成了數據的采集和存儲，接下來要進行數據的同步回流和初步處理等操作。每天上報到監控平臺的實時數據將存儲到相應的離線小時表中，我們申請對應表的權限，通過查詢表的視圖，能夠獲取到效能工具 PID 下采集的所有明細數據。

離線數據同步

由于監控平臺存儲成本有限，只能保留近 30 天的數據，且原表包括了監控平臺中所有 PID 上報的數據，數據量非常大，造成視圖查詢較慢，且查詢時若條件不嚴格，很容易因資源不足而發生查詢錯誤。因此我們考慮在 Dataworks 上建立一個周期任務，將我們需要的數據定期同步到自己創建的表中，即可解決問題。

在周期任務中，我們通過 INSERT OVERWRITE 語句，按照 ds 字段規定的分區范圍，每天向表 source_table 中寫入數據，且不會產生重復數據。將該任務發布后，它每天就會生成一個周期實例，穩定地為我們提供所需的監控數據。

數據分析 SQL 設計

我們利用 FBI 平臺來做數據分析。在 FBI 數據集編輯中，我們可以方便地基于剛才創建的 ODPS 表聲明 SQL，進一步解析自己想要的字段。

我們將 C 字段全部語義化，并運用簡單的內置函數，對數據進行空值處理或格式化處理，以備進一步利用。代碼評審數據明細分析表、代碼評審處理數據明細分析表和代碼評審匯總分析表分別聲明如下：

/*代碼評審數據明細分析表 */ SELECTa.stat_date,a.ds,a.log_day,substr(a.log_hour, 9) as log_hour,substr(a.log_time, 9) as log_time,substr(a.log_second, 9) as log_second,a.c1 as admin_name,b.c2 as project_name, -- 項目中文名信息由維表提供a.c2 as project_en_name,a.c3 as branch_name,a.c4 as target_branch,a.c5 as cr_admins,substring_index(c5, ',', 1) as cr_first_admin, -- 取得第一個評審人為主要評審人信息a.c6 as cr_admin_cnt,a.c7 as cur_req_name,concat(c4, ' ', c7) as cur_branch_and_req_name,a.c8 as cr_sequence,a.c9 as latest_version_flag,a.c10 as cur_version FROMsource_table aLEFT OUTER JOIN (SELECTcode,c1,c2FROMsource_table_dim -- 維表存儲不經常更改的維度信息) b ON a.c2 = b.c1 WHEREa.code = 'code_review'AND b.code = 'project_name'AND a.c4 != 'develop' -- 過濾掉提交到主發布分支的 CR，因為其不是關鍵信息AND a.ds > 20210630; -- 限定有數據的 ds 范圍，增加查詢性能/*代碼評審處理數據明細分析表 */ SELECTa.stat_date,a.ds,a.log_day,substr(a.log_hour, 9) as log_hour,substr(a.log_time, 9) as log_time,substr(a.log_second, 9) as log_second,a.c1 as admin_name,b.c2 as project_name,a.c2 as project_en_name,a.c3 as branch_name,a.c4 as target_branch,a.c5 as cur_req_name,concat(a.c4, ' ', a.c5) as cur_branch_and_req_name,concat(b.c2, ' ', a.c5) as cur_project_and_req_name,c.c1 as cur_req_admin_name,a.c6 as cr_count,a.c7 as cr_start_time,a.c8 as cr_end_time,datediff(to_date(a.c8, 'yyyy-mm-dd hh:mi:ss'),to_date(a.c7, 'yyyy-mm-dd hh:mi:ss'),'mi') as cr_duration, -- 使用 datediff 函數來計算CR處理時長a.c9 as latest_version_flag,a.c10 as cur_version fromsource_table aLEFT OUTER JOIN (SELECTcode,c1,c2FROMsource_table_dimWHEREcode = 'project_name' -- 關聯項目名稱信息) b ON a.c2 = b.c1LEFT OUTER JOIN (SELECTdistinct code,c1,c2,c3,c4FROMsource_tableWHEREcode = 'requirements' -- 關聯需求信息) c ON a.c5 = c.c4 WHEREa.code = 'code_review_handling'AND a.c4 != 'develop'AND a.c8 IS NOT NULL -- 沒有CR結束時間的定義為廢棄CR，此處過濾掉AND a.c8 != 'null'AND a.ds > 20210720;/*代碼評審匯總分析表 */ SELECTstat_date,project_name,project_name_and_req_name,cur_req_name,admin_name,COUNT(admin_name) as cr_cnt -- 統計CR提交次數 FROM(SELECTa.stat_date,a.ds,a.log_day,substr(a.log_hour, 9) as log_hour,substr(a.log_time, 9) as log_time,substr(a.log_second, 9) as log_second,a.c1 as admin_name,b.c2 as project_name,a.c2 as project_en_name,a.c3 as branch_name,a.c4 as target_branch,a.c5 as cr_admins,substring_index(a.c5, ',', 1) as cr_first_admin,a.c6 as cr_admin_cnt,a.c7 as cur_req_name,concat(b.c2, ' ', a.c7) as project_name_and_req_name,a.c8 as cr_sequence,a.c9 as latest_version_flag,a.c10 as cur_versionFROMsource_table aLEFT OUTER JOIN (SELECTcode,c1,c2FROMsource_table_dim) b ON a.c2 = b.c1WHEREa.code = 'code_review'AND a.c4 != 'develop'AND a.ds > 20210715AND b.code = 'project_name') GROUP BY -- 選擇日期、項目名稱、需求名稱、開發者等維度stat_date,project_name,cur_req_name,admin_name,project_name_and_req_name;

4 設計報表

產出了分析數據，接下來就可以進行報表設計與搭建了。FBI 平臺提供了豐富的圖表可供選擇，在使用時需要明確它們的含義。

圍繞著代碼評審，我們設計了以下總體和細分指標的報表。

代碼活動總覽報表

• CR 平均處理時長及健康狀況，認為 24 小時以下為健康；

• CR 平均頻次及健康狀況，認為每人每天 1-3 次為健康；

• CR 平均處理時長按開發者、需求的排行榜；

• CR 平均頻次按開發者的排行榜（為避免內卷，當頻次由高到低排列時，只展示超出健康度范圍外的數據）。

代碼活動明細報表

• 項目粒度的代碼活動健康度（CR 平均處理時長、CR 平均頻次）；

• 項目下各需求 CR 占比；

• 項目 CR 提交時間分布；

• 項目粒度的需求 CR 流轉情況（需求-開發者-主要評審人）；

• 項目下各開發者的 CR 提交頻數與負責需求數對比等。

除此之外，報表頁面還搭建了查詢詳細數據的明細列表，支持搜索各項維度數據，如項目名稱、開發者等。

5 問題洞察與解決

經過以上的報表搭建和優化，我們能初步解決首要的“看數”問題——不再擔心代碼評審產生的成本無法量化，能夠明確代碼評審具體耗時多久，也能從報表中發現和洞察潛在的問題。

案例一：總覽分析

從有數據記錄以來，發現從 7 月初到 9 月初，團隊的代碼活動明顯提升，若項目是固定的，CR 頻數卻上升了，則說明需求量可能有上升趨勢，再對比 CR 涉及的項目數趨勢，跟 CR 提交趨勢線基本吻合，說明有更多的項目利用效能工具的能力，而需求研發可以認為對于項目粒度的研發是表現正常的，但整體趨勢是項目增多，也要關注團隊同學們的業務壓力。

獲得了上述信息后，結合團隊中實際研發的項目，可逐一觀察項目粒度的明細報表數據，進一步了解業務研發情況。

案例二：異常洞察

研發效能管理者和項目負責人會關注一些異常的數據，例如超出健康度的 CR 處理時長、CR 頻次等信息。項目負責人可以立即提醒相應的開發同學或需求的對應負責人，讓其關注項目的進展情況，使該項目需求研發回到健康的狀態。

案例三：項目級效率研判

項目負責人也可以關注自己項目的代碼活動健康狀況。上圖中 A 項目 CR 平均處理時長在 4 小時左右，基本上當天問題能夠當天解決，且 CR 平均頻次為 1.8 次，說明該項目的代碼評審基本能夠無問題通過，或者一次把問題解決。項目的健康度較高。

而 B 項目的數據相對一般，CR 平均處理時長超過了 1 天，且平均每輪 CR 頻次達到了 5.5 次，不是一個健康的狀態。這時項目負責人就需要引起關注，深入項目中尋找是什么因素導致了異常，并對項目未來的進展做一些研判和決策：

• 項目排期是否正常？
• 項目開發者是否遇到了困難？
• 開發習慣和模式是否需要調整？等等。

三 思考：如何利用數據化運營解決問題？

1 數據化運營的本質是沉淀或驗證經驗

當我們接觸一個新的領域，或者對于某些業務邏輯、用戶體驗不知道當前的產品設計能否真正服務到客戶，就可以嘗試用數據化運營來幫助觀測效果，沉淀經驗，知道什么樣的設計是好的，什么樣的設計并沒有價值。

或者，借助埋點上報的真實統計數據，我們可以更客觀地驗證產品設計的價值。例如，某個數據表配置頁面，一開始用戶需要一個一個配置，效率很低；后續經過用戶調研，設計添加了一個自動同步元數據的按鈕，一鍵添加即可，用戶可能只需要修改部分字段的信息即可提交。我們通過埋點觀察用戶從打開編輯頁面到點擊保存按鈕的時間間隔變化趨勢，即能夠驗證該優化的價值所在。

2 避免過度依賴數據的誤區

數據化運營的優點可見一斑，但也需要避免一刀切地過度使用和依賴數據。當我們熟悉了所在的業務領域，通過多次的數據驗證形成經驗后，再遇到類似的場景，即可快速高效地決策。

3 數據化運營能給研發效能治理帶來什么

研發效能治理是一個長期的、持續的過程。隨著團隊支持的業務日新月異千變萬化，我們也多次迭代了效能工具來通過技術手段間接地支持著業務。

現階段，團隊所有業務的前端研發都采用現行的研發效能工具體系和數據化運營方案。搭建的數據報表主要解決“看數”的問題，可以從中主動發現異常并找到問題的根源，但數據化運營提供的能力不僅于此。

自動化信息同步機制

以往發布需求，發布負責人會運行效能工具的功能命令來打印出將要發布的需求信息，這個流程需要手動操作，且算上規范化流程中的“新建發布計劃文檔”“新建自測報告文檔”等操作，流程成本較高。

利用數據化運營，將創建的需求信息上報到監控平臺，即可利用數據進行每周定期群播報，在上線時間準確的情況下，能夠讓所有開發同學看到待上線的需求，做到信息同步。再通過周期任務機制自動化創建相應發布日期的文檔，發布流程上的成本即可大大降低。

工程化串聯

研發效能報表能做的內容遠不止 CR 效率。結合工程化整體流程，我們能夠加入需求、構建、發布、效能工具使用等相關指標，建設為報表站點。我們借此對整個工程化體系進行數據化運營，不斷優化體驗，例如提升構建速度、發布效率等，跳出研發流程管控本身，放眼更全局的視角。

實時告警和跟進

我們可以通過實時告警進一步提升主觀能動性，例如當開發者合并代碼出錯時，立即實時上報錯誤，項目負責人就能第一時間知道是代碼沖突、權限還是其他原因，并敦促需求負責人和開發者高效解決，避免阻塞項目進度。

當效能工具、工程化框架本身出現邏輯錯誤時，也能夠通過實時告警及時通知到工具開發人，無需用戶反饋即可排查和解決工具 Bug。

效能工具無人值守

進一步地，利用數據化運營，我們能夠找出最經常出現的問題，沉淀出自查文檔，在效能工具運行報錯的 catch 邏輯中為用戶提示出文檔鏈接，幫助其自主解決問題。經過一段時間到沉淀，效能工具即可做到無人值守的運營，更加提升研發效能。

綜上，我們以代碼評審效率洞察的例子了解了如何通過數據化運營的手段管控研發效能，它能夠做到平時開發準確記錄，發現問題及時解決；在解決問題的同時對團隊未來研發效能發展趨勢有了新的思考和規劃。

還是那句話，研發效能治理是一個長期的、持續的過程，我們希望能運用類似數據化運營這樣的有效方法，廣泛地實踐研發流程，深入地定義、了解、克服其中遇到的問題，使團隊研發猶如常青藤一般持續健康地發展壯大。

原文鏈接
本文為阿里云原創內容，未經允許不得轉載。

總結

以上是生活随笔為你收集整理的深入前端研发效能治理：数据化运营思路及其实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。