大型代碼庫的組織和維護：主庫、數據、UI、文檔和維基、測試、遺留組件和第三方組件……如何跟踪和維護所有這些內容的秩序？代碼庫中的文件組織可能是一項艱鉅的任務。
別擔心——我們能做到！本文將回顧小型和大型項目最常用的系統，並提供一些易於遵循的最佳實踐。
與幾乎所有與項目管理相關的任務一樣——文檔、軟件提交、部署——採取有意識的、程序化的方法將使您受益匪淺。 這不僅會減少現在的問題，而且還會在將來需要快速訪問和審查內容時為您和您的團隊節省寶貴的時間。
您肯定可以回憶起您現在正在編寫的任何內容的函數名稱，并快速找到需要編輯的文件，並清晰地分辨出哪些有效哪些無效——或者您是這樣認為的。但是，您能對您去年參與的項目說同樣的話嗎？
讓我們承認：軟件項目可能會持續數月甚至數年的不活動期。一個簡單的README文件可以為您的同事或未來的您做很多事情。但是，讓我們考慮一下您可以構建項目並建立一些基本規則的其他方法，以命名文件、處理項目文檔，並在某種程度上組織一個經得起時間考驗的有效工作流程。
我們將建立一個組織項目中文件的“基線”——一種邏輯，它將在軟件開發的範圍內為我們服務於許多情況。
與我們關於正確方式提交代碼庫更改的規則一樣，這些都不是一成不變的，而且，就其價值而言，您和您的團隊可能會提出不同的指導原則。無論如何，一致性是遊戲的名稱。確保您了解（並討論或爭論）規則是什麼，並在達成共識後遵循這些規則。
這是幾乎每個軟件項目都應該具有的文件的參考列表：
根據項目情況，您可能還需要考慮包含一些其他文件：
我們經常會遇到一組可以組合成單個概念的功能。
一些例子可能是：
所有這些都可以組織到單個“組件”或“子系統”目錄中——但不要瘋狂！
我們希望限制目錄的創建以保持事物的可管理性，無論是在根目錄（主要組件將位於此處）還是遞歸地（在每個目錄內）。否則，我們最終可能會花費大量時間例行地在精心組織的目錄中瀏覽文件。
儘管我們希望項目整潔有序，但有些文件我們希望完全排除在項目之外。
數據。您可能很想在源代碼樹中有一個data/目錄用於CSV文件等，尤其是在它們只佔用幾千字節的情況下。但是，如果它們佔用兆字節甚至千兆字節（如今這並不罕見）怎麼辦？您真的想像對待代碼一樣將這些提交到您的代碼庫嗎？不。
二進製文件。您不希望視頻渲染或編譯的可執行文件位於源代碼旁邊。這些不是開發文件，它們根本不屬於這裡。與數據文件一樣，它們也可能最終佔用大量空間。
設置。這是另一個大忌。您不應該在代碼庫中放置憑據、密碼甚至安全令牌。我們在這裡無法涵蓋解決此問題的方法，但如果您是Python開發人員，請考慮使用Python Decouple。
讓我們考慮一個Web應用程序——在Web服務器上運行的軟件，您可以通過瀏覽器訪問該軟件，無論是在台式電腦還是移動設備上。並且假設這是一個Web應用程序，它提供會員資格以訪問某種高級服務——可能是獨家報告、旅遊提示或視頻庫。
<code>├── .elasticbeanstalk ├── .env ├── billing ├── changelog.txt ├── locale │ ├── en │ └── zh_Hans ├── members ├── readme.txt ├── static │ ├── fonts │ ├── images │ ├── javascript │ └── styles ├── templates │ ├── admin │ └── frontend ├── todo.txt └── tools</code>
這是一個具有對兩種語言的支持（英語和中國大陸簡體中文（locale目錄））的基本Web應用程序結構。還有兩個主要組件，billing和members。
如果您稍微了解網站開發，則static和templates文件夾的內容可能看起來很熟悉。也許唯一不尋常的元素可能是.elasticbeanstalk，它存儲Amazon Web Services (AWS)的部署文件，以及.env，它僅本地存儲項目的設置，例如數據庫憑據。其餘的，例如README和TODO，我們已經討論過了。
tools目錄是一個有趣的目錄。在這裡，我們可以存儲腳本，例如，修剪數據庫、檢查付款狀態或將靜態文件渲染到緩存——基本上，任何不是應用程序本身但有助於使其正常運行的內容。
關於命名，如果我們命名images目錄為images/或img/，或者命名styles目錄為styles/或css/，或者命名javascript/目錄為js/，這並沒有什麼區別。主要的是結構是合乎邏輯的，我們始終遵循某種約定，無論是長的描述性名稱還是短的名稱。
現在讓我們考慮一個您可以下載並安裝到計算機上的應用程序。並且假設該應用程序需要一些輸入，例如CSV文件，然後呈現一系列報告。
在這個例子中，我們將讓源代碼樹稍微變大一些。
<code>├── .gitignore ├── data ├── doc ├── legacy │ ├── dashboard │ ├── img │ └── system ├── LICENSE ├── README ├── tests ├── thirdparty ├── tools │ ├── data_integration │ └── data_scraping ├── ui │ ├── charts │ ├── css │ ├── csv │ ├── dashboard │ ├── img │ │ └── icons │ ├── js │ ├── reports │ └── summaries ├── VERSION └── wiki</code>
ui/文件夾本質上是應用程序的核心。子文件夾的名稱幾乎是不言自明的（另一個好習慣）。與我們的Web應用程序示例不同，在這裡我們選擇了縮寫名稱（例如js而不是javascript）。再次強調，真正重要的是我們在項目中保持一致。
早些時候，我建議將數據文件排除在源代碼樹之外，但那裡有一個data/文件夾。怎麼會這樣呢？將此樹視為一個開發人員的盒子，它需要數據才能正確測試應用程序。但是，該數據仍然不在存儲庫同步之外，遵循.gitignore文件中設置的規則。
legacy/文件夾用於應用程序的一部分，該部分即將停止使用，但仍提供一些功能，直到將其完全重構到新系統中之前，這些功能可能派上用場。因此，它提供了一種將舊代碼與當前代碼分隔開來的好方法。
這里新增的還有tests/，它提供了一個使用單元測試進行質量保證的地方，以及thirdparty/，一個用於存儲軟件需要的外部庫的地方。
請注意，有doc/和wiki/文件夾，這可能看起來像是重複。但是，擁有一個面向最終用戶的文檔文件夾和一個面向開發團隊的維基也是完全可能的——甚至可以說是合理的。
值得重複的一條好消息是：即使是單獨工作也要有條理。希望本文能為您提供一些想法，您可以立即開始將其應用到您的工作流程中，以防止隨著應用程序中文件數量的增加而出現混亂。
如前所述，指導原則可能會不時發生變化，因為（幾乎）每個項目都是不同的，團隊也是如此。理想情況下，您或您的團隊將決定如何構建項目——添加一個小文檔來描述此結構的原因——然後您將從現在開始堅持這些規則。
請記住，對於這裡的許多指導原則，如果您選擇破折號或下劃線來命名文件（選擇眾多主題中的一個），這並不重要。關鍵在於一致性。
以結構化的方式組織項目文件有很多好處。首先，它提高了代碼的可讀性和可維護性。當文件以邏輯方式組織時，開發人員更容易理解代碼庫並進行更改，而不會破壞現有功能。其次，它增強了團隊協作。當多個開發人員在同一個項目上工作時，組織良好的文件結構確保每個人都知道在哪裡可以找到特定的代碼片段。最後，它加快了開發過程。開發人員花費在搜索文件上的時間更少，而花費在編寫和優化代碼上的時間更多。
項目文件的最佳結構取決於項目的性質和復雜性。對於小型項目，簡單的目錄結構可能就足夠了。但是，對於具有多個組件的較大型項目，您可能需要更複雜的結構。考慮您使用的編程語言、使用的框架或庫以及團隊的偏好等因素。重要的是要使結構靈活，以便它可以隨著項目的增長而發展。
組織代碼有幾種策略。一種常見的方法是按功能分組文件。這意味著與特定功能相關的所有文件都保存在同一個目錄中。另一種方法是按類型分組文件，例如將CSS、JavaScript和HTML文件分成不同的目錄。一些開發人員更喜歡使用混合方法，結合兩種策略的元素。關鍵是選擇一種對您的項目和團隊有意義的策略。
隨著代碼庫的增長，定期檢查和重構文件結構非常重要。這可能包括將大型文件拆分成更小、更易於管理的文件，或重新組織目錄以更好地反映項目的當前狀態。自動化工具可以幫助識別代碼庫中變得笨拙或難以維護的區域。定期的代碼審查還可以幫助確保新代碼符合已建立的文件結構。
命名約定在文件組織中起著至關重要的作用。一致、描述性的文件名使人們更容易一目了然地了解每個文件包含的內容。這可以大大加快開發過程，尤其是在處理大型項目或與團隊合作時。命名約定應該在項目開始時就商定，並始終保持一致。
為了確保所有團隊成員都遵循您的文件組織策略，重要的是要清楚地記錄您的策略並使該文檔易於訪問。定期的代碼審查還可以幫助強制執行該策略。此外，請考慮使用可以檢查是否符合您的文件組織規則的自動化工具。
是的，您可以在項目中途更改文件組織策略，但這應該謹慎進行，以免擾亂工作流程。在進行任何更改之前，請與您的團隊討論擬議的新策略，並確保每個人都了解更改的原因以及如何實施它。重要的是還要更新任何相關文檔以反映新策略。
組織項目文件時，處理依賴項可能是一個挑戰。一種方法是將所有依賴項保存在單獨的目錄中。這使得管理和更新它們變得更容易。一些編程語言和包管理器還提供用於管理依賴項的工具，這些工具可以自動化此過程的大部分內容。
組織項目文件時應避免的一些常見錯誤包括：事先不規劃文件結構、不遵循一致的命名約定、不記錄文件組織策略以及不定期檢查和重構文件結構。避免這些錯誤可以幫助保持代碼庫的整潔、組織有序且易於導航。
有很多資源可用於學習文件組織的最佳實踐。在線教程、編碼訓練營和開發人員論壇可以提供寶貴的見解。此外，研究開源項目的文件夾結構可以提供有關如何有效組織項目文件的實際示例。
以上是如何在代碼庫中正確組織文件並避免混亂的詳細內容。更多資訊請關注PHP中文網其他相關文章！
