本文轉載自公眾號“讀芯術”(ID：AI_Discovery)

假設你剛剛加入新的公司新的團隊，要開始接觸編碼庫相關的工作。你會面臨的第一個問題就是：在哪添加團隊項目的源文件呢?

[[328863]]

問得好。新團隊有三個源目錄可供添加文件，你得分清哪個是你想用的，哪個是組員用的，哪里的文件是需要重構的。

Slack iOS團隊多年來在編碼庫方面都做的較好。因為好幾次想要組建一些源文件，但又缺少編碼庫的架構模式，再者是近些年開發人員越來越多，我們來到了這個團隊。

從頂層開始

我們大約有13000個文件(還在不斷增多)，27個左右的頂層目錄，Objective-C和Swift的混合文件，大約有40個iOS開發人員在一個monorepo中工作。

Slack iOS Xcode File Hierarchy2017

這些是所有文件層次結構狀態的真實照片。新來的員工都在不斷抱怨入了編碼庫，而我們已經習慣操控這些混亂的目錄，一開始的痛苦已經不記得了。

我們有無數的源代碼目錄(特別是iOS,SlackCocoaSDK和Slack目錄)，而且確定目錄要耗費好長時間，然后再決定如何添加文件。此外，我們決定給編碼庫增添新的工具，但是目前Xcode項目的狀態不能很好地支持新增添工具的運行。

所以，我和一組ios開發人員決定開始制定以下幾點規則：

• 讓任何新老開發人員都能快速方便地添加新文件。
• 在目錄中遵循我們的設計模式
• 借助工具能夠自己維持新的且層次結構簡潔的文件夾

這將分為兩個步驟：先將頂層目錄移動到連貫的序列中(主要目標目錄、擴展目錄、框架等)，然后是大任務——源文件夾的組建。

頂層目錄的移動不存在爭議，也不難進行。可能需要幾個開發員一同花費幾周的時間。首次移動中，我們學到了一些后面階段能用到的技——錯過高峰期處理大的移動，始終合并master，及時瀏覽評論。

合并沖突不是過程中唯一棘手的事情，實際上我們可以用xcodegen更好地消除沖突，大部分沖突都存在于項目文件中。我們也想保存git歷史記錄，能一直一目了然地看到git和finder中的文件。但我們傾向更簡單的方式，讓所有人員參與進來，拖放文件到主頁。

Slack iOS Xcode Hierarchy 2017(左) and 2018 (右)

從2018年9月的這張圖可以看出，我們已經能夠成功組建頂層目錄，讓每一個目錄都適用且都是頂層目。

組建源文件

現在是時候處理iOS、SlackCocoaSDK和Slack中的源文件，把它們全部移動到App或Source中。

老實說，筆者很怕這一部分。我們需要有一個清晰的模式，能讓團隊所有的開發員都參與進來，規則和工具都要確保移動方便，工程師能清楚地看到自己是否出現失誤。

[[328864]]

圖源：unsplash

筆者對層次結構的模式展開了很多調查，竟然發現關于文件夾組建的文章少之又少。Uber在這篇文章中寫了他們是如何移動到monorepo中的(

 

https://eng.uber.com/ios-monorepo/)。這對我們如何將代碼庫分為小模塊(規模較小)提供了啟發。

最后筆者為團隊提供了三個選擇：

• 功能構建
• 主題(基于體系結構的組織)
• 本體(基于關系或類似分組的組織)

團隊會先集中主力在高級功能，然后才是主題或功能目錄中的MVVM+C。這是新結構中的一個文件夾：

/FeatureFolder 
   /Coordinators 
   /Models 
   /Tests 
      /Functional 
      /Mocks 
      /Unit 
   /ViewModels 
   /Views 

移動源文件是一項冗長繁雜的工程。處理合并沖突讓人冒火，搜索文件名稱空間來看是否將所有功能文件都拖拽到目錄中要比最初想得更難記住，而且移動的大部分文件都不符合剛開始設定的文件夾規則。

不過好在有一些勇士挺身而出，做了偉大的舉措——將iOS,SlackCocoaSDK, 和Slack都移動到App/Source中。

2020年1月層次結構文件夾的截圖：

Slack Xcode File Hierarchy2020

在移動這三個大型源目錄時，我們提出Danger規則會阻止向這些目錄中添加文件，因此會開始用我們的新模式。

Danger是持續集成系統中會用到的工具，可以執行提交后的自動檢查，同時將警告和錯誤信息發到PRS上。這是大致模樣：

has_slack_directory_additions= !git.added_files.grep(/Slack/).empty?has_slackcocoasdk_directory_additions =!git.added_files.grep(/SlackCocoaSDK/).empty?has_ios_directory_additions =!git.added_files.grep(/iOS/).empty?if has_slack_directory_additions ||has_slackcocoasdk_directory_additions || has_ios_directory_additions   fail(‘This PR is introducing new files intodirectories that are 
   closed for adding new files. Pleaseadd files to App/Source using 
   the new convention found in<ahrefahref=”…Adding-a-file-to-Slack-  
   iOS…”>Adding a file to SlackiOS</a>’, sticky: false)end 

遵循Linter

到這里還沒有結束，我們仍需移動新源目錄、App/Source中的內容。這里列了“文件夾內務管理”過程中的一些規則：

文件夾名稱不用留多余的空間(類似Bazel這類工具效果不是很好)

不要像“Helper”或“Uitility”那樣顛倒文件順序

共同定位測試(如果測試與源代碼都位于同一個功能目錄中，什么樣的方式能更容易找到測試呢?)

分類文件和文件夾!(誰不愛字母排序?!)

確保文件處于文件夾中，并且文件要與合適的目標頂層目錄相關聯。

[[328865]]

圖源：unsplash

有一條規則是真的需要共同定位測試，所以我們選擇Danger 規則。任何添加了新文件的新PR都無法加到App/Tests中。

大致如下：

has_slack_directory_additions= !git.added_files.grep(/Slack/).empty?has_slackcocoasdk_directory_additions =!git.added_files.grep(/SlackCocoaSDK/).empty?has_ios_directory_additions =!git.added_files.grep(/iOS/).empty?if has_slack_directory_additions ||has_slackcocoasdk_directory_additions || has_ios_directory_additions   fail(‘This PR is introducing new files intodirectories that are 
   closed for adding new files. Pleaseadd files to App/Source using 
   the new convention found in<ahrefahref=”…Adding-a-file-to-Slack-  
   iOS…”>Adding a file to SlackiOS</a>’, sticky: false)end 

文件夾組創建一個Slack渠道，以供人們在不確定是否添加文件的時候進行咨詢。對于往哪添加文件的困惑會比你想的多，甚至小移動都會帶來很大麻煩。

我們已經有了很大的進步，得到了來自更優秀iOS團隊的支持，但等待我們的是更多的事情。

這不是一個人能做好的工作，你需要跟編碼庫工作環節中的每一位人員協同合作起來。你需要更好的團隊，并不只是為了移動文件，而是修飾規則，添加更多的工具。有更多人的參與意味著很多人會從中學習，之后便有能力教他人如何在編碼庫工作中添加文件。

成功和幸福的秘方很簡單：假如你跟我們一樣有monorepo，那就組建一個團隊，制定硬性且能快速實現的規定。

規則可以被打破，你跟任何開發員都有機會討論，你需要核心隊伍來創建支持規則的工具，讓文件組建更水到渠成。核心成員也可以花些時間思考尋找最佳文件結構，來服務于團隊組織或工作模式。

[[328866]]

圖源：unsplash

當開發員明白在哪加文件、以什么樣的方式可以加速開發、讓自己在代碼庫的工作環境中更加自在時，世界就會變得不同。

SwiftLint、Danger、本地腳本這些工具都會助你一臂之力。但有一點需要提醒，那就是首先你需要明白工具在何處有用，這通常需要動動手指。

使用工具，共同參與，像解決其他對公司不利的問題一樣處理它。這是一件超值的事情，會讓大家更輕松地找到或添加文件，幫助開發員理解編碼庫的架構模式。

幸福是什么?是井井有條的代碼庫，是全體成員的思考和智慧，是體驗感與學習的共贏。這就是幸福呀!