幸福是一个新组织的代码库

想象一下，在一家新公司加入一个新团队，您最终可以访问代码库。

在哪里添加团队项目的源文件？问得好。您的新团队有三个源目录供您添加文件，哦，您必须找出您想要使用哪个源目录，您的队友使用哪个源目录，以及在哪里可以找到需要重构的文件。

Slake iOS团队在这样的条件下生活了几年太久了。我们之所以来到这里，是因为一些组织源文件的尝试(多次)，代码库中缺乏体系结构模式，以及几年来开发人员的高速增长。在上下文中，我们大约有13，000个文件(还在增加)，大约27个顶级目录，Objective-C和SWIFT中的混合文件，以及在一个monorepo中工作的大约40个iOS开发人员。

这些都是我们文件层次结构状态的真实照片。新员工不断地表达着跳进代码库的挫败感--这是理所当然的，因为我们中的一些人只是习惯了浏览这些混乱的目录，不记得从头开始的痛苦。我们不仅有大量的源代码目录(我们最喜欢的iOS、SlackCocoaSDK和Slake目录)，而且确定一个目录然后决定如何添加一个文件花了很多时间。最重要的是，我们决定要向代码库添加新工具，而我们Xcode项目的当前状态并不能很好地支持它们。

因此，我和一群iOS开发人员开始了一项任务：

快速轻松地添加新文件-适用于任何新开发人员或终身开发人员。

通过使用工具，使我们能够维护一个新的、更干净的文件夹层次结构。

我们分两个阶段实现了这些目标：将高级目录移动到一个连贯的顺序(如主目标目录、扩展目录、框架等)，然后-更大的任务-源文件夹组织。

最高级别的目录移动既不具争议性，也不艰难。我们和几个开发人员可能只花了几个星期的时间。在这些第一步中，我们学到了进入下一阶段的几件事-在非高峰时间处理大动作，持续合并Master(谁想要合并冲突？)，以及与员工一起进行及时的审查。合并冲突并不是我们在此过程中遇到的唯一困难，但是我们本可以投资于一种更好的方式来缓解与xcodegen的合并冲突，因为大多数冲突都在项目文件中。我们还想考虑保存我们的git历史记录，并与我们在git和finder中显示文件的方式保持清晰的约定。然而，我们选择了轻松实现文件移动，让人们参与进来，并将文件拖放到他们的新家。

如果你看这张2018年9月的图片，你会发现我们能够相当成功地组织我们的顶层。每个目录和其顶层位置中的每个目录都有一个位置，对吗？

是时候处理iOS、SlackCocoaSDK和Slack中的源文件了，以便将它们全部移到App/Source中。老实说，这部分我很害怕。我们需要在模式上达成共识，需要让所有团队的开发人员都参与进来的明确方式，以及规则和工具，以确保如果工程师做错了什么，他们的行动是容易和清晰的。我对我们的层次结构模式做了大量调查，关于文件夹组织的文章少得令人吃惊。我原以为这将是一个记录在案的话题，但作为这项工作中不那么吸引人的一部分，我可以理解为什么没有涉及到它。在我确实找到的文章中，优步写了这篇文章，讲述了他们是如何接近转向他们的单一回购的。这让我对如何将代码库分成模块(但规模较小)有了一些了解。

我最终向我的团队提出了三个选项：功能组织、主题(基于架构的组织)和本体(基于关系或类似分组的组织)。小组集中在顶层的功能上，然后在这些功能目录内进行主题或MVVM+C组织。

事实证明，移动源文件既繁琐又麻烦。合并冲突很烦人，像搜索文件命名空间以查看是否将所有功能文件捕获到一个目录中之类的小事情被证明比最初想象的更难记住，而且我们要移动的许多文件都超出了我们最初设定的文件夹规则。谢天谢地，我们有几位英雄介入，并采取了一些重大举措，将iOS、SlackCocoaSDK和Slack全部移入App/Source。

当我们移动这三个大的源目录时，我们启动了一个危险规则，以确保人们停止向这些目录添加文件，并开始使用我们的新模式。Danger是我们集成到持续集成系统中的一个工具，它执行提交后自动检查，并将警告和错误发布到PR上。这是我们其中一个人的样子：

HAS_SLACK_DIRECTORY_ADDITIONS=！git.add_files.grep(/SLACK/).空？Has_slackcoasdk_directory_addtions=！git.add_files.grep(/SlackCocoaSDK/).空吗？HAS_IOS_DIRECTORY_ADDITIONS=！git.add_files.grep(/iOS/).空？如果HAS_SLAK_DIRECTORY_ADDITIONS||HAS_SLAKCOACASDK_DIRECTORY_ADDITIONS||HAS_IOS_DIRECTORY_ADDITIONS失败(‘此PR正在将新文件引入为添加新文件而关闭的目录。请使用<；ahref=“…中的新约定将文件添加到应用程序/源。将文件添加到备用IOS…“。>；将文件添加到松弛IOS<；/a>；‘，Sticky：False)结束。

你可能会想“哇，看起来太棒了，你一定要做完了！”嗯，不完全是。我们仍在努力移动新的源目录App/Source中的内容。以下是我们在“文件夹内务”中开始实施的一些规则：

文件夹名称中不再有空格(我们想要添加的工具，如Bazel，不能很好地发挥作用)。

共同定位测试(如果我们想要真正强调在我们的新层次结构中的可发现性，我们需要用测试来加强这个游戏，还有什么方法可以比如果测试位于与源代码相同的功能目录中更容易地找到测试)。

确保您的文件位于与其目标的适当顶层目录相关联的文件夹中。

真正需要工具的一条规则是共同定位测试-为此，我们选择了危险规则。无法将添加了新文件的任何新PR添加到App/Tests。

HAS_APP_TEST_DIRECTORY_ADDITIONS=！git.add_files.grep(/Test/).空？如果HAS_APP_TEST_DIRECTORY_ADDITIONS失败(‘此PR正在将新文件引入到为添加新文件而关闭的目录中。请使用<；a href=“link-to-our-href-doc”>；iOS文件夹管家核对表<；/a>；中的新约定添加托管测试，或随时在#iOS-Testing-Folder-Structure‘，Sticky：False中询问)End。

文件夹委员会创建了一个松弛频道，如果人们不确定在哪里添加文件，可以在那里提问。关于在哪里添加文件的困惑比您想象的要多，即使是最小的举动也可能会有最强烈的意见。

我们已经取得了很大的进步，得到了更大的iOS团队的很多支持，但仍然有更多的工作要做。这不是一个人的工作，您需要招募在代码库的各个部分工作的人员。您不仅需要更强大的团队来支持移动文件，还需要更强大的团队来修改规则和添加更多工具。拥有额外的人手意味着很多人将学习这个过程，并能够向新手展示如何在我们的代码库中添加文件。

成功和幸福的秘诀出人意料地短：如果你像我们一样有一个单一的计划，那就成立一个专门从事这一过程的委员会，并制定严格的规则。规则可能会被打破，但是您可能会与任何数量的开发人员进行讨论，并且需要一个核心团队来创建工具来支持规则，使文件组织变得更加自然。核心委员会还可以花时间思考和研究最适合您的团队组织或工作模式的文件结构。

当开发人员知道在哪里添加文件，并且能够以一种促进更快的开发并真正让人在代码库中更愉快的方式来添加文件时，这将是一个非常不同的世界。像SwiftLint、Danger或自行开发的脚本这样的工具非常适合于这样的计划。然而，一个很大的警告是，您必须首先达到工具变得有用的程度，这通常需要大量的手工劳动。简而言之：使用工具，让人们参与进来，并像处理任何其他对您的公司至关重要的项目一样处理它。这是一项任务，但是让每个人都可以更容易地查找或添加文件，允许开发人员理解我们的体系结构模式，并启用工具来实施和促进更干净的代码库，这绝对是值得的。