隨著 Shopee 業(yè)務(wù)數(shù)據(jù)的不斷擴(kuò)大，僅通過(guò)表格這樣的數(shù)據(jù)分析方式已經(jīng)無(wú)法滿(mǎn)足日常的數(shù)據(jù)分析需求，豐富的圖表分析 Dashboard 就顯得格外重要。但是，從事前端開(kāi)發(fā)的同學(xué)都知道，這種 Dashboard 頁(yè)面純手工開(kāi)發(fā)會(huì)耗費(fèi)比較多的人力資源和時(shí)間資源，在量比較多的情況下，可能業(yè)務(wù)需求都沒(méi)辦法及時(shí)響應(yīng)了。

如果能有一個(gè)可以自動(dòng)生成這些 Dashboard 頁(yè)面的工具平臺(tái)，那么可以節(jié)省大量的人力和時(shí)間，效率提升將會(huì)非常顯著。本文將分享如何從零開(kāi)始創(chuàng)建一個(gè)數(shù)據(jù)可視化大屏搭建系統(tǒng)。

1.現(xiàn)狀分析

先來(lái)看一份數(shù)據(jù)。我們團(tuán)隊(duì)平均每個(gè)季度會(huì)有 3-4 個(gè) Dashboard 相關(guān)需求，平均每個(gè)需求的項(xiàng)目周期約 40 天。目前已經(jīng)累計(jì)有 20+ 頁(yè)面，每個(gè)頁(yè)面的圖表組件約 50+，另一個(gè)準(zhǔn)備重構(gòu)的平臺(tái)（Stella）Dashboard 頁(yè)面 25+，涉及到的圖表組件更多，粗略統(tǒng)計(jì) 100+。

這些 Dashboard 頁(yè)面絕大部分頁(yè)面內(nèi)容復(fù)雜，交互也復(fù)雜。按照傳統(tǒng)的開(kāi)發(fā)方式，一個(gè)頁(yè)面的上線大約需要 PM、Dev、QA 共 50+ 人/日。

除開(kāi)人力資源，接下來(lái)看看開(kāi)發(fā)一個(gè) Dashboard 的研發(fā)流程是怎樣的。

這是一個(gè)再正常不過(guò)的開(kāi)發(fā)流程。在整個(gè)流程中，用時(shí)最多的就是數(shù)據(jù)同步、接口數(shù)據(jù)聚合、頁(yè)面開(kāi)發(fā)、聯(lián)調(diào)這四大塊——大約占了 70% 的時(shí)間。如果能有一個(gè)平臺(tái)解決這幾個(gè)問(wèn)題，那么這個(gè)平臺(tái)對(duì)于 解放人力瓶頸、縮短研發(fā)流程、提高研發(fā)效率 就有著非常大的意義。

目前市面上類(lèi)似的平臺(tái)非常多，我們也做了很多橫向?qū)Ρ?。綜合來(lái)看，考慮到業(yè)務(wù)場(chǎng)景的貼近程度，以及開(kāi)發(fā)投入和收益，最終我們決定自研平臺(tái) “Data Visualization”（下文簡(jiǎn)稱(chēng) “Datav”）。

我們希望這個(gè)平臺(tái)能夠承擔(dān)的角色如下：

Datav 平臺(tái)承載了兩個(gè)主要目標(biāo)：

縮短項(xiàng)目周期，從 40 天縮短至 20 天；

減少人力成本，F(xiàn)E 從 10 人/日減少到 3 人/日，PM 從 15 人/日減少到 5 人/日，不再需要 BE 和 QA 參與。

2. Datav 設(shè)計(jì)與關(guān)鍵節(jié)點(diǎn)實(shí)現(xiàn)

為了能夠達(dá)成以上兩個(gè)目標(biāo)，我們將 Datav 要實(shí)現(xiàn)的功能抽象成了五個(gè)關(guān)鍵點(diǎn)：

• 重塑整個(gè)項(xiàng)目流程，提高 PM 和開(kāi)發(fā)之間的協(xié)作效率；
• 支持簡(jiǎn)單的元數(shù)據(jù)計(jì)算以及更加靈活的數(shù)據(jù)查詢(xún)；
• 支持頁(yè)面快速配置；
• 支持頁(yè)面組件直連數(shù)據(jù)源；
• 支持組件聯(lián)動(dòng)和篩選查詢(xún)。

2.1 整體架構(gòu)設(shè)計(jì)

接下來(lái)將一一介紹每個(gè)關(guān)鍵點(diǎn)的實(shí)現(xiàn)，下圖是我們的整體架構(gòu)設(shè)計(jì)。

整個(gè) Datav 平臺(tái)包含五個(gè)非常重要的子系統(tǒng)和模塊：

• Designer：設(shè)計(jì)器是 Datav 平臺(tái)的核心與難點(diǎn)，支持頁(yè)面布局配置、頁(yè)面交互配置和組件數(shù)據(jù)配置等功能，另外還支持代碼片段的配置，也可以稱(chēng)得上是一個(gè)低代碼平臺(tái)。
• Admin：是 Datav 的運(yùn)營(yíng)管理平臺(tái)，包含了數(shù)據(jù)計(jì)算、作品管理、組件狀態(tài)管理、頁(yè)面發(fā)布、頁(yè)面權(quán)限等等常規(guī)的平臺(tái)管理功能。
• UI Components：是整個(gè)平臺(tái)最基礎(chǔ)的模塊，我們?cè)陂_(kāi)源的圖表庫(kù)上面定義了一層標(biāo)準(zhǔn)的 DSL 協(xié)議，這個(gè)協(xié)議和接入 Designer 的協(xié)議是對(duì)應(yīng)的，目前已經(jīng)有 50+ 相關(guān)組件，組件數(shù)量還在不斷增長(zhǎng)。
• Datav Server：是一個(gè) node 服務(wù)，主要提供一些權(quán)限校驗(yàn)、數(shù)據(jù)聚合、動(dòng)態(tài) SQL 的生成等功能。
• Datasource Access Server：專(zhuān)門(mén)用于連接不同數(shù)據(jù)源的服務(wù)，例如直連 MySQL、ClickHouse、Elasticsearch、Presto 等等，提供了不同的連接 client。

從架構(gòu)圖可以看出，Datav 平臺(tái)支持直連各種數(shù)據(jù)源，最終會(huì)產(chǎn)出一個(gè) URL，可以方便地集成到任何平臺(tái)上。下一步計(jì)劃是支持生成源代碼，可供使用方進(jìn)行二次編輯。

2.2 如何提高各個(gè)角色之間的協(xié)作效率

在解決這個(gè)問(wèn)題之前，我們和各個(gè)角色之間進(jìn)行了多次溝通，分析了各個(gè)角色在項(xiàng)目中的痛點(diǎn)以及花費(fèi)的成本：

• PM 側(cè)的痛點(diǎn)是畫(huà)原型圖，每個(gè)需求畫(huà)原型圖需要花費(fèi) 10 天左右的時(shí)間，而且還是靜態(tài)的圖片，跟開(kāi)發(fā)對(duì)完需求后，還需要去改里面的一些靜態(tài)數(shù)據(jù)，然后再進(jìn)行 PRD 評(píng)審；
• BE 和 FE 主要的精力花在頁(yè)面開(kāi)發(fā)、接口開(kāi)發(fā)、數(shù)據(jù)同步以及頁(yè)面聯(lián)調(diào)這些事情上。

從傳統(tǒng)的開(kāi)發(fā)流程來(lái)看，這些都是正常的流程，是最小開(kāi)發(fā)路徑。要解決這個(gè)問(wèn)題，我們就需要重塑整個(gè)項(xiàng)目的流程，讓各個(gè)角色都能參與到配置中來(lái)，于是我們一起重新定義了 Dashboard 項(xiàng)目的開(kāi)發(fā)流程，如下圖。

• PM 可以直接在 Datav 上面配置原型頁(yè)面；
• Data Dev 也支持直接將數(shù)據(jù)計(jì)算的結(jié)果自動(dòng)同步到 ClickHouse；
• FE 可以通過(guò) Datav 直連數(shù)據(jù)源，并且可以復(fù)用步驟 1 里面 PM 配置的原型頁(yè)面，進(jìn)行配置優(yōu)化；
• 最終生成頁(yè)面的 URL，PM 可以直接訪問(wèn) URL 進(jìn)行測(cè)試。

新的流程效果非常顯著，整個(gè)項(xiàng)目周期縮短了一半，從 8 周縮短到了 4 周，也不再需要 BE 和 QA 的支持，F(xiàn)E 平均只需要投入 3 天支持需求。

2.3 如何支持元數(shù)據(jù)計(jì)算

2.3.1 基礎(chǔ)知識(shí)

支持元數(shù)據(jù)計(jì)算是個(gè)比較復(fù)雜且龐大的功能。數(shù)據(jù)是所有系統(tǒng)的基石，任何平臺(tái)和業(yè)務(wù)都離不開(kāi)數(shù)據(jù)的流轉(zhuǎn)。同時(shí)，數(shù)據(jù)的流轉(zhuǎn)也是非常復(fù)雜的，特別是在數(shù)據(jù)量比較龐大的情況下。

我們先來(lái)認(rèn)識(shí)一下數(shù)據(jù)的產(chǎn)生和流轉(zhuǎn)都做了什么事情，以及從客戶(hù)端產(chǎn)生數(shù)據(jù)開(kāi)始，到 Dashboard 看到數(shù)據(jù)的聚合，都經(jīng)歷了哪些階段。

上圖是一個(gè)常規(guī)的大數(shù)據(jù)平臺(tái)的架構(gòu)圖，它清楚地描述了數(shù)據(jù)產(chǎn)生到數(shù)據(jù)應(yīng)用的整個(gè)過(guò)程。可能里面有一些專(zhuān)有詞匯對(duì)于 FE 來(lái)講有點(diǎn)陌生，但這里我們只需要了解：用戶(hù)所產(chǎn)生的數(shù)據(jù)，需要經(jīng)過(guò)一系列的加工之后，才會(huì)有比較大的價(jià)值。

下面再用一個(gè)更容易理解的流程圖來(lái)說(shuō)明：

從圖中可以看出，數(shù)據(jù)準(zhǔn)備有四個(gè)關(guān)鍵流程， 數(shù)據(jù)采集、數(shù)據(jù)預(yù)處理、數(shù)據(jù)建模、數(shù)據(jù)服務(wù) ，每個(gè)階段都有一系列的事情要做，Data Dev 同學(xué)可以借助數(shù)倉(cāng)以及相關(guān)工具，快速產(chǎn)出業(yè)務(wù)所需要的數(shù)據(jù)，Datav 平臺(tái)不會(huì)涉及到這部分的功能，Datav 所處理的是在數(shù)據(jù)服務(wù)之后。

這里從數(shù)倉(cāng)產(chǎn)出的數(shù)據(jù)，雖然經(jīng)過(guò)了一系列的計(jì)算，但是往往也不是頁(yè)面展示想要的數(shù)據(jù)。根據(jù)經(jīng)驗(yàn)來(lái)看，一個(gè) Dashboard 頁(yè)面往往會(huì)有非常多的數(shù)據(jù)聚合邏輯，也就是說(shuō)還需要根據(jù)數(shù)據(jù)服務(wù)產(chǎn)出的數(shù)據(jù)進(jìn)行數(shù)據(jù)聚合。例如要計(jì)算同比、環(huán)比這樣的指標(biāo)等等。

2.3.2 Datav 打通數(shù)據(jù)直連通道

業(yè)務(wù)方需要做數(shù)據(jù)聚合，也就意味著需要后端開(kāi)發(fā)提供 API 接口給前端。數(shù)倉(cāng)產(chǎn)出的數(shù)據(jù)，由于環(huán)境隔離和權(quán)限等原因，目前無(wú)法直接給業(yè)務(wù)團(tuán)隊(duì)使用，因此業(yè)務(wù)團(tuán)隊(duì)使用這些數(shù)據(jù)有一個(gè)特別曲折的過(guò)程，使得整個(gè)流程比較復(fù)雜、鏈路也比較長(zhǎng)。

這個(gè)流程 BE Dev 階段需要提供兩個(gè)服務(wù)，一個(gè)數(shù)據(jù)同步服務(wù)，一個(gè) API 接口服務(wù)。粗略統(tǒng)計(jì)，BE Dev 這一步需要花費(fèi)整個(gè)項(xiàng)目流程 30% 左右的時(shí)間，而且這些工作也是重復(fù)的。

因此 Datav 解決的第一個(gè)問(wèn)題——打通數(shù)據(jù)直連通道，采用的方案就是直連 ClickHouse。

Datav 提供了一個(gè) 直連數(shù)據(jù)源的服務(wù) ，可以直接連接 Data Infrastructure 團(tuán)隊(duì)提供的 ClickHouse，這樣一來(lái)，大部分 Dashboard 頁(yè)面就有了直連數(shù)據(jù)源的能力，不再需要依賴(lài) BE 團(tuán)隊(duì)提供 API，使整個(gè)項(xiàng)目周期縮短了 30% 左右的時(shí)間。

上面提到，API 主要作用是用于一些數(shù)據(jù)聚合和數(shù)據(jù)邏輯計(jì)算的，那么 Datav 是如何支持這些功能的呢？這就是 Datav 面臨的第二個(gè)大的挑戰(zhàn)——支持?jǐn)?shù)據(jù)聚合計(jì)算以及邏輯字段增加。

2.3.3 支持元數(shù)據(jù)計(jì)算

接下來(lái)用一個(gè)簡(jiǎn)單的例子來(lái)說(shuō)明：Datav 如何實(shí)現(xiàn)替代 API 接口支持一些數(shù)據(jù)聚合計(jì)算。例如，有一個(gè)銷(xiāo)售表 tab_sales（這是數(shù)倉(cāng)計(jì)算出來(lái)的離線數(shù)據(jù)），內(nèi)容如下：

現(xiàn)在有一個(gè)需求：要求計(jì)算每個(gè) category 的支付成功率。

按照以前的方式，API 接口會(huì)按照類(lèi)型先把數(shù)據(jù)查出來(lái)，查詢(xún) SQL：

得到原始數(shù)據(jù)后需要進(jìn)行計(jì)算，得到最終右側(cè)的數(shù)據(jù)結(jié)構(gòu)給到前端：

試想，如果 Datav 能夠產(chǎn)生這樣一條 SQL，查詢(xún)出來(lái)的結(jié)果也能夠返回同樣的數(shù)據(jù)結(jié)構(gòu)，是不是就可以不用依賴(lài) API 接口了？帶著這樣的疑問(wèn)，我們做了很多的嘗試。

最終結(jié)論證明，在大部分場(chǎng)景下，完全能夠不用依賴(lài) API 接口。就如同上面的例子，我們將 SQL 變化一下，就能夠得到相同的數(shù)據(jù)結(jié)構(gòu)：

2.3.4 Datav 數(shù)據(jù)管理

為了解決上述兩大問(wèn)題——如何打通數(shù)據(jù)直連通道、如何支持元數(shù)據(jù)邏輯計(jì)算，Datav 建設(shè)了數(shù)據(jù)管理模塊。

數(shù)據(jù)管理是比較重要的一個(gè)模塊，在配置頁(yè)面之前，第一步想到的應(yīng)該是這個(gè)頁(yè)面的數(shù)據(jù)都來(lái)自哪，頁(yè)面中每個(gè)組件的數(shù)據(jù)都來(lái)自哪張表，是否是通過(guò)某些字段計(jì)算得到的等等問(wèn)題。

因此，數(shù)據(jù)管理模塊應(yīng)該包含幾大塊：數(shù)據(jù)源管理、數(shù)據(jù)字段編輯（包括字段名別名、新增字段、支持字段間的計(jì)算、字段格式化、字段展示權(quán)限等）、數(shù)據(jù)主題管理（支持多表間關(guān)聯(lián)產(chǎn)生邏輯數(shù)據(jù)寬表，以及自定義 SQL 查詢(xún)生成數(shù)據(jù)主題）。流程如下：

1）數(shù)據(jù)源管理

目前數(shù)據(jù)源支持直連離線數(shù)據(jù)源（MySQL、ClickHouse），即將支持直連實(shí)時(shí)數(shù)據(jù)源（Kafka、Elasticsearch、Prometheus 等）。

2）數(shù)據(jù)字段編輯

字段編輯提供了針對(duì)表以及表字段的別名設(shè)置、表字段權(quán)限設(shè)置、新增邏輯字段、字段邏輯計(jì)算、字段格式化等一些列高級(jí)功能。

3）數(shù)據(jù)主題管理

數(shù)據(jù)主題目前支持可視化配置和自定義 SQL。目前可視化配置僅支持單表設(shè)置，即將支持多表關(guān)聯(lián)形成邏輯寬表。

多表關(guān)聯(lián)功能如圖：

自定義 SQL 查詢(xún)?nèi)鐖D：

2.4 如何支持頁(yè)面快速配置

支持頁(yè)面快速配置的核心就是 Designer 的實(shí)現(xiàn)。跟目前業(yè)界低代碼平臺(tái)實(shí)現(xiàn)的思路類(lèi)似，都是通過(guò)將頁(yè)面組件的位置信息、屬性用一種通用的中間協(xié)議 DSL 來(lái)描述，然后通過(guò)解析引擎在運(yùn)行時(shí)動(dòng)態(tài)去解析 DSL，再渲染到頁(yè)面中。

架構(gòu)如下圖：

為了進(jìn)一步提高 UI 和 FE 之間的協(xié)作效率，我們預(yù)留了一些高級(jí)功能。

• 例如實(shí)現(xiàn)一個(gè) Figma 插件，可以讓 UI 在設(shè)計(jì)頁(yè)面的時(shí)候就用到我們的組件，然后通過(guò)這個(gè)插件生成頁(yè)面的 DSL 產(chǎn)物，再交給 Datav 解析引擎去做頁(yè)面渲染；
• 還有一種更加大膽的想法，就是通過(guò)機(jī)器學(xué)習(xí)的方式，將圖片中的組件識(shí)別出來(lái)，自動(dòng)生成頁(yè)面的 DSL 產(chǎn)物，最終再交給 Datav 解析引擎去做頁(yè)面渲染。

這兩種方案都還處于設(shè)計(jì)階段，暫時(shí)還沒(méi)有實(shí)現(xiàn)。

Designer 這一塊功能比較多，而且比較復(fù)雜，這里就不展開(kāi)細(xì)節(jié)講。我們目前已經(jīng)實(shí)現(xiàn)了兩種頁(yè)面布局的方式：絕對(duì)布局和 Flex 布局。針對(duì)不同的場(chǎng)景，采用不同的布局方式，頁(yè)面配置效率會(huì)非常高。

Flex 布局：適用于頁(yè)面結(jié)構(gòu)簡(jiǎn)單且清晰，類(lèi)似 Admin 表單類(lèi)型頁(yè)面的配置場(chǎng)景。

絕對(duì)布局：頁(yè)面結(jié)構(gòu)復(fù)雜且組件布局毫無(wú)規(guī)律的頁(yè)面配置，大屏頁(yè)面就特別符合。

2.5 頁(yè)面組件直連數(shù)據(jù)源

組件直連數(shù)據(jù)源的關(guān)鍵點(diǎn)包括：

• 理解維度和指標(biāo)；
• 理解如何生成一個(gè) SQL 語(yǔ)句。

接下來(lái)先用兩個(gè)例子直觀說(shuō)明：

這是一個(gè)二維一指標(biāo)的圖表，一個(gè)維度是日期，即 X 軸；另一個(gè)維度是柱子的分類(lèi)，指標(biāo)就是 Y 軸的數(shù)據(jù)。

如果要生成這樣一個(gè)圖表，那我們的 SQL 語(yǔ)句應(yīng)該這樣寫(xiě)：

Select [indicator] from [table_xxx] group by [dimension1], [dimension2]

從 SQL 語(yǔ)句中可以發(fā)現(xiàn)，維度屬性放在 group by? 后面，指標(biāo)屬性放在 Select 后面。

再來(lái)看一個(gè)例子：

同理，這是一張一維一指標(biāo)的圖，對(duì)應(yīng)的 SQL 如下：

Select [indicator] from [table_xxx] group by [dimension1]

理解了維度和指標(biāo)，以及 SQL 的生成規(guī)則后，基于這樣的思路，我們實(shí)現(xiàn)了一個(gè) Data-Connector 組件，這個(gè)組件可以配置維度、指標(biāo)、分頁(yè)、排序等字段，最終再根據(jù)這些配置生成一個(gè)對(duì)應(yīng)的 SQL 語(yǔ)句。

它對(duì)應(yīng)生成的 SQL 語(yǔ)句是這樣的：

SELECT field1 FROM Demo-Table GROUP BY date_day LIMIT 1000 OFFSET 100 ORDER BY  field3  ASC

這樣，我們就實(shí)現(xiàn)了組件直連數(shù)據(jù)源，展示對(duì)應(yīng)的動(dòng)態(tài)數(shù)據(jù)。

2.6 支持組件聯(lián)動(dòng)和篩選查詢(xún)

在絕大部分的場(chǎng)景下，我們配置出來(lái)的頁(yè)面不是一個(gè)靜態(tài)頁(yè)面，它需要?jiǎng)討B(tài)數(shù)據(jù)，也需要各種交互，最常見(jiàn)的就是篩選這種交互。

交互對(duì)于頁(yè)面配置來(lái)講是一個(gè)難點(diǎn)，因?yàn)榻换ヌ貏e多，有些交互也特別復(fù)雜。Datav 目前只支持了部分交互，例如組件數(shù)據(jù)篩選、按鈕點(diǎn)擊事件、彈窗、tab 切換等等比較常見(jiàn)的功能。

我們先看一個(gè)例子，為什么一定要支持組件間的交互呢？

這是我們利用組件直連數(shù)據(jù)源查詢(xún)出來(lái)的數(shù)據(jù)，你會(huì)發(fā)現(xiàn)數(shù)據(jù)量非常大。

這個(gè)時(shí)候，有可能會(huì)導(dǎo)致組件崩潰或者頁(yè)面卡死。因此，解決這種問(wèn)題最好的方式就是支持?jǐn)?shù)據(jù)篩選，即支持一個(gè)組件可以篩選另一個(gè)組件的數(shù)據(jù)，如下圖。

這就是我們希望獲得的效果：用一個(gè)篩選組件控制圖表組件的數(shù)據(jù)量。那么如何實(shí)現(xiàn)呢？

我們也調(diào)研了業(yè)界的類(lèi)似方案，最常用的就是支持寫(xiě)代碼，利用發(fā)布訂閱設(shè)計(jì)模式來(lái)實(shí)現(xiàn)。實(shí)現(xiàn)原理大致如圖：

這樣做的優(yōu)勢(shì)非常明顯——簡(jiǎn)單，但是同樣也存在一些不足：

• 需要寫(xiě) JS 代碼，只對(duì)前端同學(xué)比較友好；
• 如果關(guān)聯(lián)組件比較多，那代碼維護(hù)將會(huì)變得非常復(fù)雜；
• 頁(yè)面配置的效率也會(huì)大大降低。

因此，為了解決這些問(wèn)題，Datav 實(shí)現(xiàn)了可視化配置組件聯(lián)動(dòng)，對(duì)于復(fù)雜的情況，也支持寫(xiě)代碼的方式。實(shí)現(xiàn)原理也不復(fù)雜，總結(jié)起來(lái)分成四個(gè)步驟：

• 建立篩選組件和展示組件的關(guān)聯(lián)關(guān)系，以及篩選組件和篩選參數(shù)的關(guān)系；
• 監(jiān)聽(tīng)篩選參數(shù)的變化；
• 一旦篩選參數(shù)發(fā)生變化，通知所有相關(guān)聯(lián)的展示組件，并將新的值傳遞給它；
• 通知工具函數(shù)拉取新的數(shù)據(jù)并重新渲染。

原理架構(gòu)圖如圖：

整個(gè) Datav 平臺(tái)比較龐大，有非常多的功能點(diǎn)，很多功能點(diǎn)的設(shè)計(jì)都可以單獨(dú)寫(xiě)一篇文章來(lái)介紹。而本篇文章主要圍繞 Datav 解決的一些關(guān)鍵問(wèn)題來(lái)展開(kāi)，我們希望通過(guò)這篇文章讓大家了解到 Datav 是一個(gè)什么平臺(tái)，能解決哪些問(wèn)題，適用于哪些業(yè)務(wù)場(chǎng)景。因此在技術(shù)細(xì)節(jié)上面并沒(méi)有太多的展開(kāi)，后續(xù)會(huì)另寫(xiě)文章介紹。

3. Datav 帶來(lái)的收益

Datav 項(xiàng)目帶來(lái)的收益可以從流程優(yōu)化、開(kāi)發(fā)效率，和基礎(chǔ)建設(shè)等方面來(lái)考量。

3.1 流程優(yōu)化

整個(gè)項(xiàng)目流程的周期從原來(lái)的 40 天左右減少到了現(xiàn)在的 20 天左右。耗費(fèi)的人力也有所減少，不一定需要 BE 和 QA 同學(xué)的加入了，項(xiàng)目周期縮短了 100%。

這是因?yàn)?PM 同學(xué)可以直接通過(guò) Datav 平臺(tái)配置頁(yè)面的原型，確定好需求后，這個(gè)原型配置可以直接交給 FE 同學(xué)進(jìn)行加工，加上一些交互和數(shù)據(jù)相關(guān)配置，就可以直接提測(cè)。

3.2 開(kāi)發(fā)效率

單從前端的開(kāi)發(fā)效率來(lái)看，平均 10 人/日縮短到了平均 3 人/日，效率提升 200% +。

從整個(gè)研發(fā)階段的效率來(lái)看，以前需要參與的人力總和為： (Data dev) 10 人/日 + (BE Dev) 13 人/日 + (FE Dev) 10 人/日 = 33 人/日 。

現(xiàn)在人力總和為： (Data dev) 10 人/日 + (FE Dev) 3 人/日 = 13 人/日 ，從 33 人/日縮短到了 13 人/日，效率仍然提升了 150% +。因此 Datav 對(duì)于研發(fā)效率的提升來(lái)講，也是意義非凡的。

3.3 基礎(chǔ)建設(shè)

除了上面提到的量化收益，Datav 還帶了比較多的隱性收益，例如在團(tuán)隊(duì)基礎(chǔ)建設(shè)上的：

• 制定了組件開(kāi)發(fā)規(guī)范；
• 建立了一套標(biāo)準(zhǔn)組件庫(kù)以及組件平臺(tái)；
• 沉淀了一些標(biāo)準(zhǔn)的 Node 中間件，例如 logger；
• 沉淀了一套標(biāo)準(zhǔn)的自動(dòng)化腳本，組件創(chuàng)建、自動(dòng)編譯、自動(dòng)化生成文檔、代碼規(guī)范檢測(cè)等等；

更細(xì)粒度的權(quán)限管理系統(tǒng)（建設(shè)中）。

本文作者

Liangquan、Huiwen、Mingye、Yanqiu，前端工程師，來(lái)自 Shopee Digital Purchase & Local Services 團(tuán)隊(duì)。

團(tuán)隊(duì)介紹

Shopee 數(shù)字產(chǎn)品與本地生活（Digital Purchase & Local Services）團(tuán)隊(duì)業(yè)務(wù)涉及數(shù)字商品的售賣(mài)服務(wù)，包括話費(fèi)、游戲充值等生活繳費(fèi)，電影、演出等娛樂(lè)票務(wù)，以及火車(chē)票、飛機(jī)票、公交票等出行 OTA 服務(wù)。

我們已經(jīng)覆蓋東南亞日常大部分?jǐn)?shù)字商品消費(fèi)場(chǎng)景，市場(chǎng)規(guī)模龐大，具有交易頻度高、用戶(hù)黏度高等特性。我們還為用戶(hù)提供便捷的本地生活服務(wù)，包括餐飲、娛樂(lè)、購(gòu)物等，這些都是線下支付的重要場(chǎng)景和流量入口。目前服務(wù)已覆蓋大部分東南亞市場(chǎng)，用戶(hù)規(guī)模龐大且進(jìn)一步擴(kuò)展。