故事板似乎是处理 iOS 中多个视图控制器以及它们之间的转换的一种优雅方式。
但是，到目前为止，我一直避免使用它们，因为担心多个开发人员对同一故事板文件中的视图控制器进行更改时会发生什么，以及可能导致的合并冲突。
在中等复杂度的生产应用程序中，有没有人在这方面有很多实践经验？
您的评估是什么？在这方面，故事板准备好迎接“黄金时段”了吗？还是更适合单个开发人员或小型开发团队？
（还有一些变通方法，例如“分片”到多个故事板文件中？）
意见？
谢谢！
【问题讨论】：
标签： ios uikit uistoryboard uistoryboardsegue
一点背景：
我的五人团队、四名开发人员和 QA 刚刚完成了一个相当大的项目（超过 50k 行代码），该项目使用了大量的 Storyboard。我们至少有 10 个不同的故事板，其中许多在导航结构中深入 5 或 6 层。
此外，我们严重依赖通过 Perforce 进行的版本控制，每天有几十个签入。
我的经历：
我从来没有考虑过使用我们的任何故事板来处理解决方案。版本控制对它们的处理非常好，主要有两个原因。首先，如果您打开一个，您会看到它是结构良好的 XML，它与版本控制配合得非常好。其次，对于故事板，您总是希望在添加任何细节或代码之前布局整个 UI 结构（这就是重点）。这非常适合团队编码解决方案，因为每个成员都可以获取一个单独的 ViewController 并实现它，从而与团队的其他工作保持隔离。
但是，我建议您进行一些“分片”，因为您可以轻松获得一个巨大的连接巢。
最后：
如果您在网上浏览一下，您会发现很多对 Storyboard 的负面反应，因为将数据从一个视图传递到另一个视图会变得“混乱”。但是，如果您让自己陷入这种情况，那么您已经违反了 MVC 的基本原则。您不应该使用您的视图来存储和管理数据。起初这很诱人，也很容易，但随着项目超出基础，最终会给您带来麻烦。
【讨论】：
合并冲突仍然是 Apple 尚未解决的大问题（包括在 Xcode 4.6 中）。有时，仅查看情节提要内容会导致其被修改。修改似乎是 nib 的无害内部工作，但如果 2 个人查看故事板而不进行修改，保存文件，然后提交，您可能会看到您不了解如何合并的冲突。我不久前对此提出了一个错误，它被标记为与已知问题的重复。
另请参阅支持这一点的这些问题：
http://robsprogramknowledge.blogspot.com/2012/01/uistoryboard-best-practices.html
【讨论】：