30 天 21 個版本 OCAP Playground 都經歷了哪些變化？

剛剛過去的七月是我十年來在北京度過的最熱的月份，我負責的 OCAP Playground 始終處於緊鑼密鼓的開發當中，整個七月發布了 21 個內部版本，版本號從 0.7.3 到 0.11.2，你看到這篇文章的時候，線上的版本號很可能已經大於 0.11.2 了。

為什麼會有這麼多內部版本？難道發布版本是不花時間的嗎？可以很自豪地說，發布這麼多新版本對我們來說毫不費力，是因為我們可以用極快的速度交付，每個 Playground 新版本從建置到上線時間都在 10 分鐘以內，並且都是自動化的。如果你好奇 ArcBlock 技術團隊的這種交付速度是怎麼煉成的，何不讀讀 ArcBlock 技術 VP 的文章《如何在幾十個 Repo 中遊刃有餘？》

不多廢話，下面是截圖自 GitHub 的 Playground 近 30 天程式碼合併記錄（實際上這頁沒放下）：

做過網際網路產品的同學可能會嘀咕：單月這麼多次迭代，到底定了幾個目標？Playground 作為架構在 OCAP 服務上的首款應用，是開發者接觸 OCAP 服務的窗口，所有的迭代始終圍繞如何讓開發者用起來爽進行，具體來說包括下面幾個關鍵目標：

關注 ArcBlock 專案進展的同學可能會問：我也時不時開啟 Playground，沒發現介面上有太大的變化啊？接下來我們來扒一扒到底這些迭代都體現在哪些地方。

改進的表格視圖：Table View

人類可讀的資料展示

改進後的表格視圖會盡可能地把 OCAP 服務返回的資料格式化成人類可讀的格式，比如比特幣網路上的轉帳金額、帳戶餘額，會格式化成以 BTC 為單位並帶上千位分隔符的數字，而區塊大小則格式化成 KB、MB 格式的數字，如下圖：

可互動的資料展示

改進後的表格視圖會把帳戶地址、交易地址、區塊地址格式化成能夠跳轉到區塊瀏覽器對應地址的連結（比如 blockchain.com、etherscan.io），節省開發者自己複製、貼上和查找的步驟，如下圖：

巢狀資料的支援

表格視圖不僅僅能支援簡單行列式的結果展示，也能支援多層巢狀的資料，內層資料透過浮層展示，如下圖：

特別大的表格

當查詢回來的資料比較多，全部放在表格視圖裡面，會擁擠不堪，可讀性極差，遇到這種情況，我們會優先展示重要的欄位在縮略表格中，在使用者展開表格之後展示所有的行列，如下圖。

改進的圖表視圖：Chart View

有句話叫「文不如表、表不如圖」，恰當的資料視覺化能讓人一眼瞥見資料中的模式、特徵甚至是問題，所以我們也花了比較多的時間來研究怎麼做區塊鏈資料的視覺化，下面是兩個具體的進展。

區塊鏈資金流視覺化：Sankey Diagram

區塊鏈網路就是張巨大的價值流動網路，價值流動的載體就是交易，而 Sankey Diagram 在視覺化網路流時非常直觀，於是有了下面的視覺化支援：

如果查詢結果中包含交易資料，並且交易裡面包含了傳送方、接收方，Playground 會自動探測到，並在圖表類型中增加 Sankey 支援，比如下面的查詢：

{
  transactionsByAddress(sender: "1NSc6zAdG2NGbjPLQwAjAuqjHSoq5KECT7") {
    data {
      blockHash
      blockHeight
      fees
      feesOverWeight
      hash
      index
      total
      lockTime
      numberInputs
      numberOutputs
      size
      strippedSize
      version
      virtualSize
      weight
      witnessHash
      inputs {
        data {
          account
          blockHash
          blockHeight
          index
          txHash
          preOutput
          preTx
          value
          script
          sequence
          scriptType
          txHash
          txIndex
        }
      }
      outputs {
        data {
          account
          blockHash
          blockHeight
          index
          script
          scriptType
          txHash
          txIndex
          value
        }
      }
    }
  }
}

我還想偷偷地告訴你，就在使用 Sankey Diagram 的過程中，我透過視覺化發現了資料上的 bug，並回饋給了負責的同事。

區塊列表資料視覺化：BlockList

擬物化、形象化也能讓資料更加鮮活，讓資料特徵躍然紙上，區塊裡面打包的是交易，就像個盒子，那為什麼不以盒子的形態來呈現區塊資料呢？

如果查詢結果中包含了區塊列表，Playground 會自動增加 BlockList 圖表的支援，比如下面的查詢：

{
  blocksByHeight(fromHeight: 500000) {
    data {
      height
      hash
      total
      size
      transactions {
        data {
          blockHash
          blockHeight
          fees
          feesOverWeight
          hash
          index
          total
          lockTime
          numberInputs
          numberOutputs
          size
          strippedSize
          version
          virtualSize
          weight
          witnessHash
          inputs {
            data {
              account
              blockHash
              blockHeight
              index
              txHash
              preOutput
              preTx
              value
              script
              sequence
              scriptType
              txHash
              txIndex
            }
          }
          outputs {
            data {
              account
              blockHash
              blockHeight
              index
              script
              scriptType
              txHash
              txIndex
              value
            }
          }
        }
      }
    }
  }
}

更高的工程品質

在產品易用性之外，我們也很關注程式碼品質、擴充性等，因為在這些方面的投入具有很大的複利效應，具體來說我們做了下面這些事情：

為關鍵模組增加自動化測試

為了減少 bug 率和保證迭代速度，我們給 Playground 中的大部分關鍵程式碼增加了單元測試，每次程式碼合併會以所有測試通過為前置條件，目前整個儲存庫的分支覆蓋率達到了 33%，如下圖：

使用 styled-components 管理元件樣式

前端專案如何管理樣式在專案變大時也會成為比較重要的問題，我們使用 styled-components 來管理元件的樣式，保證每個前端元件的高內聚，降低應用不同部分樣式之間的耦合性，現在程式碼儲存庫中除了全域樣式外，沒有單獨的樣式檔案。

使用 sentry 收集線上報錯

沒有人能寫出沒有 bug 的軟體，我們也不例外，但是出了 bug 第一時間知道並最快修復並不是所有人都能做到，我們在線上環境整合了 sentry 來收集 JS 錯誤，任何使用者使用過程中的錯誤都會被捕捉下來，透過 slack 傳送給每個專案的負責人，並以盡可能快的速度修復。

其他改進

為了保證程式碼風格，我們會強制 travis-ci 對 warning 級別的風格提示直接報錯，強制開發者修改，因為我們深知破窗效應在軟體開發領域同樣起作用，今天你忽略它，總有一天它會回來狠狠地咬你一口；為了在團隊成員間提高程式碼重用度，減少重複造輪子，我們還整合了 storybook 來管理儲存庫中的前端元件，方便新人快速了解儲存庫中有哪些立刻可用的元件。

新產品方向：Playbook

在我們內部討論過程中，產生了一個新的產品形態：Playbook，方便區塊鏈開發者研究、記錄、分享自己在 OCAP 服務上所做的研究、發現，目前 Playbook 已經開發出了雛形，相信不久之後，我們再打磨打磨即可對外公布，感興趣的同學歡迎閱讀我編寫的：《Introduction to OCAP Playbook》，不想去閱讀的也可以看看截圖：

結語

正如我在《OCAP Playground 入門指南》中所講，現代系統大都是大後端小前端，整個七月 OCAP 服務前端進展如上，那麼後端所做的事情就更多了，後續會有文章跟大家介紹。

轉眼，八月已經來了，我們會一如既往地在既定的路線圖上繼續前行，為建設 ArcBlock 的生態而努力。我們最近還在大量招前端、後端工程師，北京和西雅圖都要，如果你對區塊鏈行業感興趣，欣賞我們做事的方式，歡迎來聊，職位介紹見這裡，當然，你也可以直接把履歷給我（微信：feweekly）。