真正的团队如何处理iOS Storyboard

故事板。你不能和他们住在一起。没有他们，你活不下去。作为团队一部分构建iOS应用的任何人都知道，合并地狱中有一个特殊的圈子专门解决此特定问题。

使用源代码控制， 将所有应用程序的UI设计放在单个文件中是不现实的。 您团队中的太多人将触摸该文件。很快，任何东西都不会自动合并，因为情节提要中存在冲突。

当然，我们还希望故事板附带所有假定的好处。原则上，希望在一个视图中查看应用程序的整个流程似乎是合理的。不用说，拥有用于设计UI的可视工具真的很棒。

多年以来，我们一直吃着蛋糕，但也无法食用。为什么？这似乎是我们应该能够解决的问题。

我参与的最好的团队总是会在第一天就了解某种情节提要策略。通常就是这样。

1.没有故事板代表通过应用程序的整个流程。

2.每个情节提要板代表应用程序中的单个屏幕，如果需要，则为View Controller。

3.每当您打算重用视图时，请继续使用它自己的nib文件创建一个自定义UIView子类。

4.散步，享受一生中额外的5个小时，因为您不再需要在同一个该死的整体XML文件中解决合并冲突。

当然，如果您做这些事情，您似乎会错过情节提要的关键卖点。您已经放弃了一个文件可以神奇地向我们展示应用程序所有屏幕上所有用户旅程的想法。

也许这首先是一个误导的愿景。也许在这样的想法中只存在边际效用，并且一直使用情节提要的人（阅读过实际的开发人员）并没有从中获得任何价值。

您当然可以提出一个案例，即一个情节提要不一定会浮出水面。通常，注销用户会将用户带到某个开始屏幕，如果您查看情节提要，这并不是很明显。

因此，似乎我们想要的真正工具比我们现有的工具复杂得多。

首先，我认为苹果公司或决定接受这一挑战的任何人都必须承认形势的现实。 不再有理智的开发人员在他们的项目中使用单个故事板。 这样做是因为无法使用源代码管理来处理您的应用程序。

因此，也许有一些单独的开发人员正在执行此操作，但是除非您拥有某种团队，否则项目无法真正快速扩展。

考虑到现实，我们如何改变它？

也许我们可以在真正使用它们时开始提及它们。故事板，至少是我和我团队使用它们的方式，与其说是故事板，不如说是一个单一屏幕的表示。 因此，我们称它们为屏幕。

屏幕可以连接到其他屏幕。不同的控制器可以管理如何显示不同的屏幕。屏幕概念的本质是屏幕与其相邻屏幕的关系。

有了这个想法，我们就腾出了故事板，以表示它们本来应该具有的含义。遍历应用程序中所有屏幕之间的所有关系时，将得到一个故事板。

作为开发人员，故事板不应该成为您要操纵的东西。 它应该是您在各个屏幕上完成的工作的计算结果，可以在需要时随时查看的高级视图。

这样的工作完成了吗？并非如此，至少我不能用我微弱的Google搜索能力来分辨。也许这是在苹果公司秘密进行的。

如果是这样，俗话说，除了拥有蛋糕，我们还可以吃蛋糕。

暂时，实际上已经达成一致，如果要使用情节提要来可视化地设计View Controller，则应将每个View Controller分成自己的情节提要。

这样，如果给定的故事板文件中存在任何合并冲突，则将它们限制在单个View Controller中，而不是整个应用程序中的所有View Controller。

您仍然必须处理情节提要文件中的偶尔合并冲突。它仍然会像往常一样吮吸。但是， 您将不再发现自己正在搜索单个整体文件以找到一个或两个位置，您需要在这些位置确定要接受还是拒绝哪些更改。

如果通常更容易处理情节提要文件中的合并冲突，那么它也可能会有所帮助，但是看起来情况永远不会改变。在一个完美的世界中，我们将克服冲突，就像它们是一系列设计决策一样。

您可以想象一些人工智能助手工具会问：

“这个分支说你想要Oceanside Blue，但是另一个说你想要Steel Blue。哪个蓝色？”

尽管您一直在听到有关奇点的所有信息，但我们离现实还很遥远。

目前，我们只需要阻止自己和我们的同事进入合并地狱的第九圈。 请帮个忙，给每个屏幕自己的故事板。

如果您喜欢阅读本文，请推荐并订阅。如果您要我谈论任何与iOS或Swift相关的问题，请问！