然而,我一直避免使用它们,因为担心多个开发人员对同一个故事板文件中的视图控制器进行更改后可能引起的合并冲突。
有没有人在生产应用程序中亲身体验过这种情况,特别是涉及中等复杂性的应用程序?
您如何评价故事板在这方面的可用性?它更适合单个开发人员或小型开发团队吗?
还有其它解决办法,例如将它分成多个故事板文件进行处理吗?
请给出您的意见。谢谢!
一些背景信息:
我的团队由四名开发人员和一名QA组成,刚刚完成了一个相当大的项目(50,000+行代码),其中使用了大量的Storyboard。我们至少有10个不同的Storyboard,其中许多都有5或6级导航结构。
此外,我们非常依赖 Perforce 进行版本控制,每天有几十次提交。
我的经验:
在我们的所有Storyboard中,我从未考虑过如何处理解决冲突。Storyboard 的版本控制处理得非常好,原因有两点。首先,如果您打开一个Storyboard,您将看到它是良好结构化的 XML,与版本控制非常兼容。其次,对于Storyboards,您始终会希望在添加任何细节或代码之前布置整个 UI 结构(这就是整个重点)。这非常适合团队编码解决方案,因为每个成员都可以拿起一个独立的 ViewController 并实现它,与团队其他成员的工作保持隔离。
但是,我建议进行一些“分片”,因为您很容易陷入一个巨大的连接混乱的境地。
最后:
如果您在网上搜索一下,就会发现许多负面反应是针对Storyboard的,因为从一个视图传递数据到下一个视图可能会变得“混乱”。但是,如果您陷入了这种情况,那么您已经违反了MVC的基本原则。您不应该使用视图来存储和管理数据。这在开始时很诱人和容易,但最终会使您的项目超越基础知识时陷入麻烦。
合并冲突仍然是苹果公司尚未解决的一个大问题(包括Xcode 4.6)。有时,只是查看故事板内容就会导致其被修改。这些修改似乎是nibs的无害内部工作,但如果两个人在没有进行修改的情况下查看一个故事板、保存文件,然后提交,你可能会看到你不知道如何合并的冲突。我之前曾经报告了一个错误,并标记为已知问题的重复。
另请参阅以下支持此观点的问题:
http://robsprogramknowledge.blogspot.com/2012/01/uistoryboard-best-practices.html