大型代码库的组织和维护：主库、数据、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中文网其他相关文章！
