MBox 是由字節(jié)跳動抖音基礎技術(shù)團隊和 Client Infrastructure 團隊根據(jù)移動端研發(fā)出現(xiàn)的現(xiàn)狀與問題，結(jié)合移動端研發(fā)工具相關(guān)實踐經(jīng)驗，自研的一款面向移動端開發(fā)者的研發(fā)工具鏈產(chǎn)品。目前，MBox CLI (Command Line Tool) 已經(jīng)開源，后續(xù)將增加更多平臺支持，歡迎試用。

現(xiàn)狀與問題

隨著公司的快速發(fā)展，移動端研發(fā)呈現(xiàn)出以下的現(xiàn)狀與趨勢：研發(fā)團隊規(guī)模參差不齊，工程化與組件化方案不盡相同，跨端研發(fā)成為常態(tài)，中臺業(yè)務不斷擴大等，而這些現(xiàn)狀使得移動端開發(fā)不得不面臨下面的問題：日益復雜的研發(fā)環(huán)境與工程架構(gòu)。

• 研發(fā)環(huán)境

在大前端背景下，移動端研發(fā)環(huán)境呈現(xiàn)出豐富的技術(shù)棧背景，這也導致了研發(fā)環(huán)境的復雜度提升。研發(fā)環(huán)境部署是編碼的前置工作，這也是新人對團隊研發(fā)體驗的第一印象，因此研發(fā)環(huán)境的問題會給團隊帶來不少的麻煩。其實，并非僅有新人才遇到研發(fā)環(huán)境的問題，隨著工程化推進，環(huán)境問題會持續(xù)困擾著團隊所有成員，環(huán)境版本不一致、工程環(huán)境沖突、頻繁更新文檔，這些問題會使得研發(fā)人員將大量精力浪費在環(huán)境上，而不是核心的編碼與測試階段。

• 工程架構(gòu)

很多移動端研發(fā)人員經(jīng)常面對著的是超大型工程或者多個工程并行開發(fā)的場景，項目的工程架構(gòu)往往十分復雜，這通常體現(xiàn)在多倉依賴管理困難、發(fā)布流程繁瑣、多人協(xié)作難度變大，極大地影響研發(fā)效率。這里又引發(fā)了另一個思考，上述的部分問題其實是我們在工程化改造過程中所引入的，而這是否與工程化提高效率、保證質(zhì)量的目的相違背呢？

漸漸地研發(fā)流程變得愈發(fā)繁瑣，研發(fā)效率將不可避免地受到影響，可能在這之初研發(fā)人員會怨聲載道，但長此以往便也習以為常了。

工具鏈面臨的挑戰(zhàn)

半自動化的流程

在移動端開發(fā)的場景下，研發(fā)人員盡管擁有看似豐富的研發(fā)工具來解決上面的環(huán)境與工程問題，但開發(fā)者們時常會有工具找不到、工具不會用與工具不好用的感受。理想狀態(tài)下，工具鏈中每個工具的輸出或者結(jié)果環(huán)境將成為下一個工具的輸入或起始環(huán)境，但在移動研發(fā)的實踐中，工具鏈之間的輸出與輸入轉(zhuǎn)換時常需要研發(fā)人員手動完成，這種大量的重復性操作也成為研發(fā)人員吐槽的焦點。

維基百科：工具鏈是一組編程工具，通常是另一個計算機程序或一組相關(guān)程序。

被割裂的流水線

每一個研發(fā)團隊都有著自己的研發(fā)流水線（評審、開發(fā)、構(gòu)建、測試、修復、發(fā)布），在提升研發(fā)效能的實踐中我們往往會提供豐富的研發(fā)工具供研發(fā)人員在這些流程節(jié)點中使用，但這些工具真的有合理地融入到我們的研發(fā)流程中，形成一條完整的工具鏈嗎？

真實情況是，我們在實踐中常常過多地關(guān)注單一指標，例如通過對工具鏈的改造提升項目的工程化程度，工程化確實能帶來可維護性、工程質(zhì)量等指標的提升，但是在其他環(huán)節(jié)中，如新人上手成本提升、依賴管理難度提高、代碼合入時間拉長、Bug 復現(xiàn)困難等方面也帶來了負面影響。

方案

我們對上述的現(xiàn)狀與問題進行了分析，并結(jié)合在移動端研發(fā)工具相關(guān)實踐經(jīng)驗，最終決定開發(fā)一款面向移動端開發(fā)者的研發(fā)工具鏈產(chǎn)品 MBox。

如上圖所見，MBox 最終所呈現(xiàn)的產(chǎn)品形態(tài)是一款包含 GUI (Graphical User Interface) 與 CLI (Command-Line Interface) 的 Navtive App。

理念

全覆蓋 All-in-one

我們期望開發(fā)一款能夠?qū)ρ邪l(fā)流程做到全場景覆蓋的工具鏈產(chǎn)品，用戶能夠在 MBox 中獲取所有需要的研發(fā)信息，并完成相應的研發(fā)工作，同時確保在整個研發(fā)鏈路中擁有一致的研發(fā)體驗。

可視化 Visualized

在最初迭代 CLI 版本的過程中，我們漸漸發(fā)現(xiàn)可視化的交互方式可以解決一些在 CLI 交互中難以解決的問題，盡管 GUI 相比 CLI 在編程實現(xiàn)上會復雜很多，但我們堅信用戶體驗的重要性，因此 MBox 為用戶提供了 GUI 與 CLI 兩種可供選擇的交互方式。

極簡化 Simple

這里的 Simple 并不是指簡單，而是交互設計上的簡約，在這里本質(zhì)上是可用性的體現(xiàn)。我們認為研發(fā)工具應該是為用戶解決困難而不是制造困難的，任何無關(guān)的或是分散研發(fā)人員注意的信息都是不必要的，簡單好用是對一款研發(fā)工具的最美稱贊。

可擴展 Extensible

通常意義下 All-in-one 的工具鏈往往會導致可定制性變差，MBox 通過插件化技術(shù)在最大程度上滿足了用戶在橫向與縱向上擴展性需求。

架構(gòu)

上文中提到通常情況下我們的研發(fā)流程是一條流水線式的模型，多數(shù)研發(fā)工具都會從這條流水線中找到一個切入點來提供服務，協(xié)助用戶完成某個節(jié)點的工作。而 MBox 在架構(gòu)設計上則更多關(guān)注的是整個研發(fā)流程運轉(zhuǎn)的效率，這不僅體現(xiàn)在單個節(jié)點的高效，同樣體現(xiàn)在不同節(jié)點之間流轉(zhuǎn)的高效。

MBox 在功能上并沒有按照研發(fā)流程進行劃分，而是將整條研發(fā)鏈路貫穿到所有的功能設計中，根據(jù)功能的種類分成四大板塊：Environment、Workspace、Workflow、Tool。

核心功能

Environment

Environment 即研發(fā)環(huán)境，直覺告訴我們環(huán)境部署只是研發(fā)環(huán)節(jié)中較為前置的一個環(huán)節(jié)，但在實際開發(fā)實踐中，Environment 要解決的不僅僅是部署（Deployment）的問題，其中還包含了環(huán)境統(tǒng)一（Consistency）、環(huán)境升級（Upgrade）和環(huán)境隔離（Isolation）這三個問題，而上述的四個問題卻是貫穿于整個研發(fā)流程的。

我們認為在一個良好的研發(fā)體驗中，研發(fā)人員無須關(guān)注絕大部分與環(huán)境相關(guān)的問題，應該把更多的關(guān)注度放在業(yè)務上，產(chǎn)生更多有效的價值。MBox 實現(xiàn)了整個過程的自動化，在任意時刻，無感知地為研發(fā)人員提前完成環(huán)境相關(guān)的部署、隔離與升級工作，同時還解決了項目研發(fā)環(huán)境一致性的問題。

上圖展示了 GUI 下的環(huán)境功能模塊，除了上文中提到的全自動化能力，MBox 同樣支持用戶手動控制。

Workspace

Workspace 是我們代碼倉庫存放的空間，也被認為是研發(fā)人員工作的核心。我們首先可以回顧一下，通常情況我們是如何管理代碼的？在這過程中我們又遇到了哪些問題？

下文將闡述我們在實踐過程中遇到的困難以及對應的解決方案。

挑戰(zhàn) 1：跨項目開發(fā) Multiple Projects

在一些研發(fā)團隊中（常見于中臺部門），常常需要在多個項目之間同時進行開發(fā)，每一個項目的代碼倉庫與研發(fā)環(huán)境往往是迥異的，研發(fā)在切換項目的過程中常常疲于解決各種倉庫與環(huán)境問題，導致效率降低。MBox 采用沙盒化 Sandbox 技術(shù)，將不同項目的代碼倉庫與環(huán)境隔離開來，我們將這樣的沙盒稱之為 MBox Workspace（以下簡稱 Workspace），在這樣的機制下，研發(fā)人員只需要明確當前自己需要開發(fā)哪個項目而無需關(guān)注這個項目背后的問題。

挑戰(zhàn) 2：倉庫繁多 Too Many Repos

隨著團隊增長，工程化、組件化不斷深入，理想狀態(tài)下每個業(yè)務團隊只需要關(guān)注自己開發(fā)的組件，代碼以倉庫為級別進行隔離，這樣做確實也會帶來不少在緩存、二進制、安全風控等方面的優(yōu)勢，但這也可能會導致一個常見問題，即倉庫數(shù)量龐大而變得難以維護。

在 MBox 中研發(fā)人員可以輕松地將遠程或者本地的倉庫添加到 Workspace 中進行統(tǒng)一管理，同時在同一 Workspace 中我們還利用緩存技術(shù)加速用戶添加倉庫的過程，讓倉庫的增刪變得更加方便快捷。

除了倉庫的增刪，研發(fā)人員們最常用的還是 Git 倉庫操作，MBox 參考了業(yè)內(nèi)成熟的方案并結(jié)合自己的實踐經(jīng)驗，以 CLI 與 GUI 兩種方式為研發(fā)人員提供了多倉庫批量操作的支持。

上面展示了 GUI 下多倉庫提交的過程，在終端下用戶可使用 mbox git xxx 命令來完成多倉批量操作。

挑戰(zhàn) 3：需求多變 Change of Requirements

大多數(shù)研發(fā)人員常常面臨需求變化的問題，比如同時開發(fā)多個需求或者臨時的 Bug 修復，在 GitFlow 模型下，研發(fā)人員需要根據(jù)當前需求來回切換對應分支，尤其是在多倉開發(fā)中，頻繁的需求變化會給研發(fā)人員增加大量成本。

MBox 通過簡化 GitFlow 模型，提出 Feature Mode 概念，每一個需求的元數(shù)據(jù)（即倉庫、分支、代碼）被抽象成為了一個 Feature，每個 Feature 之間相互獨立互不影響，允許研發(fā)人員可以在多個需求之間快速輪轉(zhuǎn)。

從上圖中可以看到，當前 Workspace 存在 3 個 Feature，分別是 feature1 feature2 bugfix，每個 Feature 擁有各自對應的同名分支。除此以外 MBox 還存在 Free Mode 的狀態(tài)，在該狀態(tài)下研發(fā)人員可以對倉庫進行任意的操作，作為切換到 Feature Mode 的前置準備。

挑戰(zhàn) 4：依賴復雜 Complex Dependency

在移動端的本地開發(fā)中，我們常常需要將某個組件依賴替換成本地倉庫中的源碼版本，同時還需要小心地維護著本地倉庫的代碼版本，以確保和集成版本一致。

MBox 具備一套完整的依賴管理方案，結(jié)合不同的包管理工具特點，利用多種技術(shù)實現(xiàn)了對依賴包的本地重定向，研發(fā)人員只需要一行命令或者點擊幾個按鈕即可完成該操作，盡可能減少研發(fā)人員重復的機械性工作。

與此同時，通過一套抽象的依賴管理方案我們在一定程度上抹平了依賴管理工具之間的一些差異性，即便是在跨端開發(fā)中，研發(fā)人員依舊可以獲得較為一致的研發(fā)體驗。例如在組件化研發(fā)場景中，我們需要依賴本地的源碼版本的組件 A，F(xiàn)lutter 和 iOS 平臺上常用的包管理工具對應的 CLI 命令分別是

• Flutter

$ mbox add component_A$ mbox pub get

• iOS

$ mbox add component_A$ mbox pod install

挑戰(zhàn) 5：協(xié)作困難 Collaboration

隨著團隊的擴大，團隊成員之間的協(xié)作變得更加緊密，但與此同時項目的復雜程度同樣會隨著團隊的增長而增長。如何將自己的研發(fā)進度及時且完整地同步給其他人，成為了提升團隊協(xié)作效率所必須要解決的問題。

上文中已經(jīng)提到 Feature Mode 的抽象過程，其實 Feature 不僅可以使得單個研發(fā)人員快速切換工作上下文，也允許不同研發(fā)人員共享自己當前狀態(tài)下的所有代碼倉庫及其研發(fā)環(huán)境。

我們還可以發(fā)揮更多的想象力，如果將這一功能擴展至云平臺，比如異常監(jiān)控平臺，由服務端構(gòu)造出會發(fā)生某個崩潰 case 的 Feature ，研發(fā)人員將其導入本地，即可快速在本地復現(xiàn)出 Bug 出現(xiàn)的場景。

Workspace 的優(yōu)勢

結(jié)合上述的五個挑戰(zhàn)中，我們分別提出了與之相對應的解決思路，即利用沙盒化技術(shù)解決跨項目開發(fā)問題，利用多倉管理技術(shù)解決倉庫數(shù)量膨脹問題，提出 Feature 概念解決多需求并行問題，利用依賴管理技術(shù)解決依賴控制低效的問題，最后提出了同步 Feature 來解決多人協(xié)作困難的問題

Workflow

研發(fā)流程相關(guān)的云服務

在大型工程團隊中，為了提升研發(fā)質(zhì)量和效率，會推出很多與研發(fā)流程相關(guān)的云服務，這些服務的一般是通過前端頁面或是命令腳本對外提供服務。但很多云服務都面臨著同樣的問題，無法及時地觸達每個研發(fā)人員，落地往往都需要一定的時間，同時研發(fā)人員也需要付出一定的學習成本。我們一直在思考，如何幫助那些優(yōu)秀的云服務發(fā)揮出最大的價值？

在實踐中，我們發(fā)現(xiàn)云服務在結(jié)合了 MBox 的 Native 優(yōu)勢后，不僅大幅降低了用戶的學習成本，同時也能夠擴展云服務使用的場景。

上文中提及的 MBox 與異常監(jiān)控平臺的聯(lián)動，就是一個很好的應用場景，監(jiān)控平臺通過 MBox 直接為研發(fā)人員創(chuàng)建了本地開發(fā)環(huán)境，將云服務的應用場景擴展至研發(fā)人員本地。云平臺通過 MBox 可以實現(xiàn)與研發(fā)人員本地機器的聯(lián)動，研發(fā)人員也能通過 MBox 直接使用線上的云服務，可以說 Native 解決了云服務工具“觸達用戶最后一公里”的問題，同時也為這些云服務帶來了更大的想象空間。

智能錯誤診斷

在移動研發(fā)中，相當一部分的工具鏈是運行在研發(fā)人員本地機器上的，導致我們無法實時獲取研發(fā)人員本地的運行狀態(tài)，這也加大了排查問題的難度。另外，研發(fā)人員在研發(fā)流程中遇到報錯或者疑問時，也缺少自我排查的方法，多數(shù)情況只能求助身邊同事或者發(fā)起 Oncall。

MBox 借助自身作為一款 All-in-one 研發(fā)工具的優(yōu)勢，收集研發(fā)人員在各個流程中遇到的錯誤日志，進行分析和歸類，在第一時間為研發(fā)人員推送問題的解決方案，盡可能地減少工具問題對研發(fā)效率的影響。作為工具鏈開發(fā)者，可以通過不斷補充解決方案來優(yōu)化錯誤診斷的流程 ，沉淀出通用問題的知識庫來提升人工 Oncall 的前置攔截率。

Tools

MBox 不僅僅是一個研發(fā)工具，它更像是一個可以承載更多研發(fā)工具的平臺 ，MBox 開放了所有的核心能力，所有開發(fā)者都可以通過插件的形式對它進行二次開發(fā)，將好用的工具分享給更多的開發(fā)者。

為什么是 Native App?

核心功能介紹完了，最后還是想談談為什么我們要做一款 Native App。

多數(shù)傳統(tǒng)實踐中我們常常利用“工具 平臺 文檔”三者的緊密配合來保障整個研發(fā)流程的運轉(zhuǎn)，然而正是這種過于緊密的關(guān)系容易導致三者之間相互影響而阻塞開發(fā)。順著這個思路，既然這三者存在著如此緊密的聯(lián)系，那么是否可以存在這樣一個載體將這三者統(tǒng)一成一個整體，滿足研發(fā)人員在研發(fā)流程中的所有需求，確保研發(fā)這條流水線的高效運轉(zhuǎn)。

既然作為 Native 開發(fā)者，為什么不為自己開發(fā)一款稱手的研發(fā)工具來提升自己的工作效率？

這個很酷的想法就應運而生了，像做產(chǎn)品一樣來做工具，核心圍繞移動端本地研發(fā)。將產(chǎn)品思維應用到工具開發(fā)中，持續(xù)不斷提升工具的可用性，我們堅信只有可用性高的研發(fā)工具產(chǎn)品才能真正起到提升研發(fā)效能的作用。同時在產(chǎn)品思維的驅(qū)動下，我們還可以利用 MBox 建立了效能度量數(shù)據(jù)指標，發(fā)現(xiàn)研發(fā)流程的關(guān)鍵問題，進行針對性開發(fā)和優(yōu)化，形成使用產(chǎn)品 -> 收集數(shù)據(jù) -> 改進產(chǎn)品的閉環(huán)。

尼爾森對產(chǎn)品可用性的認識：易用性、交互效率、易記性、容錯性、用戶滿意度

開放性

開放性賦予了工具鏈強大生命力。

能力開放

MBox 在設計之初就使用了插件化的架構(gòu)，自底向上完全遵循插件化開發(fā)的思路，盡可能地將所有能力開放出來，用戶通過 MBox 提供的開發(fā)者套件來開發(fā)自定義插件，實現(xiàn)定制化能力。正因為有了如此開放的自定義能力，MBox 對研發(fā)流程支持的廣度和深度將持續(xù)不斷地進化。

平臺開放

MBox 允許任何開發(fā)者可以將自定義插件上傳至插件市場，同時團隊技術(shù)負責人可以結(jié)合團隊選擇需要的插件集合，插件市場將負責同步團隊內(nèi)所有成員的插件及其對應版本。除此以外，所有用戶也可以在插件市場這個平臺上瀏覽和安裝任何對自己研發(fā)效率提升有幫助的插件。通過這樣一個開放的平臺，在字節(jié)跳動內(nèi)部已有來自多個不同的研發(fā)團隊的數(shù)十個插件被發(fā)布至插件市場，功能涵蓋了研發(fā)的各個流程，逐步建立起了一個開放的工具鏈生態(tài)。

如果說上面提到插件化架構(gòu)很好地解決了插件“從哪里來”的問題，那么插件市場就很好地解決了插件“到哪里去”的問題。

思考

全鏈路與可定制

在選在研發(fā)工具鏈時，通常會有兩種選擇：

一種是全鏈路型的工具，即一套完整的解決方案覆蓋研發(fā)的所有場景，在該方案下，所有研發(fā)數(shù)據(jù)流動會更加順暢，用戶體驗更佳。

另一種是定制化工具，即結(jié)合當前團隊的研發(fā)流程、人員結(jié)構(gòu)、技術(shù)特點，自由選擇最適合的工具鏈組合，將各個工具的長處發(fā)揮到極致。

從表面上看 MBox 似乎更像前者，即一款全鏈路的工具，但本質(zhì)上 MBox 在做的是將后者的定制化工具組做一次整合，解決各個工具之間數(shù)據(jù)流轉(zhuǎn)問題，提供一站式的工具鏈服務，打造研發(fā)體系的閉環(huán)。MBox 并不是要取代任何一個環(huán)節(jié)的工具，因此對于一般項目而言 MBox 的接入過程十分簡單，我們的目的是將工具和開發(fā)者連接起來，最大程度地提升研發(fā)效能與用戶體驗。

再論研發(fā)流水線

上文提到研發(fā)流水線的概念，在傳統(tǒng)實踐過程中，圍繞著這條流水線會孕育出各種工具平臺，來協(xié)助研發(fā)人員完成這條流水線。然而，正如文章開頭提到，工具鏈大多都專注于研發(fā)流程的某個節(jié)點，常常忽略了流水線節(jié)點流轉(zhuǎn)的流暢性。

我們?yōu)槭裁慈绱岁P(guān)注生產(chǎn)節(jié)點之間流轉(zhuǎn)的流暢性？

在提升研發(fā)效能實踐中，提升生產(chǎn)節(jié)點流轉(zhuǎn)的效率與提升單一節(jié)點效率一樣重要。生產(chǎn)節(jié)點流轉(zhuǎn)的流暢性其實最終體現(xiàn)在我們能夠為用戶提供一個靈活性強且易用性高的生產(chǎn)工具，因為實踐中發(fā)現(xiàn)，前端研發(fā)人員們往往在一個多變的處境中，需求多變（同時開發(fā)多個需求或同時修復多個 bug）、環(huán)境多變（開發(fā)環(huán)境經(jīng)常需要升級或切換版本）、工具多變（技術(shù)進展帶來的工具變化）。研發(fā)人員時常直面這些變化卻難以從容應對，尤其在面對流程切換所導致的效率損失時而倍感壓力。

工具能夠為研發(fā)人員提供足夠的靈活性，是確保生產(chǎn)節(jié)點流轉(zhuǎn)效率的關(guān)鍵。MBox 有意識地為用戶提供了盡可能多的靈活性，支持了從需求到編碼、需求到需求、實現(xiàn)到準入、編碼到合碼、線上問題到本地排查等多個流程的靈活流轉(zhuǎn)。

結(jié)束語

自智能終端設備誕生起，移動端研發(fā)已蓬勃發(fā)展十余年，每個平臺框架都已經(jīng)發(fā)展出了一套獨特的工具鏈體系，每個大型團隊內(nèi)部也已經(jīng)建立起了一個個內(nèi)部的工具體系，但正是這一個個獨立而又成熟的工具體系將成為了束縛我們施展技術(shù)的牢籠。在大前端背景下，技術(shù)棧界限變得模糊，移動端開發(fā)者們?nèi)绻軌虼蚱七@些限制，將我們的經(jīng)驗與技術(shù)應用到更廣闊的未來之中，這是多么令人激動的事！最后希望 MBox 在這方面一些微不足道的思考和工作，能夠重新喚起我們移動端開發(fā)者們改變世界的偉大愿望。

One More Thing

MBox CLI (Command Line Tool) 已經(jīng)開源啦！現(xiàn)已支持 CocoaPods (iOS) 與 Bundler 項目，后續(xù)將增加更多平臺支持。通過開源，我們希望更多的開發(fā)者能夠加入到 MBox 的生態(tài)建設中來，為廣大的移動端開發(fā)者帶來一款出色的研發(fā)工具。

GitHub 地址：

• https://github.com/mboxplus/mbox

參考鏈接

• https://en.wikipedia.org/wiki/Toolchain
• https://github.com/nvie/gitflow
• https://www.atlassian.com/devops/devops-tools/choose-devops-tools
• https://flutter.dev/
• https://gradle.org/
• https://cocoapods.org/

加入我們

我們是負責抖音客戶端基礎能力研發(fā)和新技術(shù)探索的團隊。我們在工程/業(yè)務架構(gòu)，研發(fā)工具，編譯系統(tǒng)等方向深耕，支撐業(yè)務快速迭代的同時，保證超大規(guī)模團隊的研發(fā)效能和工程質(zhì)量。在性能/穩(wěn)定性等方面不斷探索，努力為數(shù)億用戶提供最極致的基礎體驗。

如果你對技術(shù)充滿熱情，歡迎加入抖音基礎技術(shù)團隊，讓我們共建億級全民 App。目前我們在上海、北京、杭州、深圳均有招聘需求，內(nèi)推可以聯(lián)系郵箱：liyao.ryan@bytedance.com ，郵件標題：姓名 – 工作年限 – 抖音 – 基礎技術(shù) – iOS/Android 。