情节提要

“卢克·天行者？ 我以为他是个神话。”

回到我开始担任iOS开发人员时，我被告知故事板太可怕了，不适合团队协作。

好。 看起来确实很合理。 那么替代品是什么？ 自动布局代码？

该团队最终使用了手动框架计算。

这是一个布满虫子的烂摊子。 手动计算每个组件的帧本身就很繁琐，而且只会因没有MVC结构可言且无需进行任何重构而变得更加糟糕。 到处查看，都有一行添加子视图或设置边框宽度，并且您经常需要滚动浏览数十页的UI代码，以检查某些控制逻辑。

好吧，这听起来像是您的团队很烂，但帧计算很烂，尽管使用自动布局可能是最新的。 您可能会回应。

是的，这也是我的想法，当该项目完成时，我开始解决所有架构问题。 我当时正在为基于自动布局的开发做准备，我注意到情节提要，独自一人坐在黑暗中。

Xcode，是爱还是恨？

令人惊讶的是，今天我的许多同事仍然使用与2010年相同的思维方式和工作流程。几乎没有任何第三方框架，但AFNetworking只是用于检测网络可达性。 包括UI在内的所有内容都写在viewDidLoad（）中。 框架是手工计算的，也放置在viewDidLoad（）中。 此类活动于2016年举行。

起初，我认为这可能是一个久经考验的传统，并且在一个又一个的项目中得到反复证明。 这是做iOS的规范方法，我实在太笨了，无法理解它。 这个故事讲述了一个故事板吃着初级开发人员，并在晚上自动布局偷孩子的故事。

但是帧计算没有任何意义！ 一个组件的框架中的任何更改，都必须重新计算所有其他受影响的组件，并且它会逐渐消失。 很难想象有一位高级开发人员，说他有3到5年的经验，仍然需要计算每个按钮和每个标签。 那看起来不像是一条有希望的职业道路。

由于没有在任何地方使用界面生成器，因此Objective-C是开发语言。 我最好用Appcode代替Xcode。

* 单击 *。 Appcode可以正常工作。 那时，我意识到了反人类Xcode的UI设计是多么的好。 当我浏览文件或通过断点进行调试时，我希望“打开新标签”为默认选项。 但是Xcode以其无限的智慧甚至否认了我。

至此，我以为我找到了解决方案。 Appcode +自动布局。 通过一个项目又一个项目一次又一次地测试时间。 我花了很大的精力为团队介绍自动布局和适当的第三方框架，并完成了所有步骤以及文件和示例的必要工作。

如果不是因为一次偶然的google尝试，故事可能会很开心，故事就此结束。

西斯领主？

试图将MVC引入其他团队成员。 我认为编写任何内容都不是确定的设计模式。

当然，这就是为什么要进行自定义视图的原因。 但是在此过程中，我还注意到，必须仔细并反复运行该应用程序并导航到正确的页面以检查UI是否正确，这很烦人。

好的，经过一番谷歌搜索后，找到了IBDesignable和XIB来预览自动布局代码。 但是XIB不支持原型单元，因此无法预览表格视图，这相当于视图的70％。

OK，所以放下XIB，然后使用情节提要。 不用了 如果我仍然要使用情节提要，为什么还要先编写自动布局代码，然后再用IBDesignable的所有开销在情节提要中查看；为什么？ 我不妨将其绘制在情节提要上。

然后，我搜索了一些关于代码vs xib vs故事板的经典讨论。 结果是……不确定。 问题在于许多文章都过时了，经过数年的更新可能不准确。 尤其是其中一位引起了我的注意，这是几年前写的，他说他在一个小型团队中成功使用了故事板。

好吧，如果某人能在多年前实现这一目标，那么考虑到我也是一个小团队，我就没有理由现在无法实现这一目标。

最初，这就像我开始学习iOS时所记得的那样令人沮丧。 但是，困难与陌生之间是有区别的。 也许是因为Xcode更新了，或者我只是git gud，所以一切都变得有意义了。 最终* 单击 *。

如果您避免这种情况，并在发生其他事情时执行该操作，则并不难。 哦，请记住在那之后执行此操作，您将看到它确实有效 。

听起来很讽刺。 但事实并非如此。 因为回报是值得的，至少对于我的项目而言，是值得的。 我能理解为什么故事板在早期是不可行的，甚至在早期甚至是自动布局，但在我撰写本文时（距2018年不到一个月的时间），我看不到在团队协作中使用它时出现问题，而我在团队协作中使用它。

我认为80–20原则适用于可可粉。 您可以在自定义视图或情节提要中进行80％的常规视图设置，并在viewDidLoad（）中进行20％的进一步设置以解决运行时情况。 80％的视图只是情节提要所具有的处理能力而已； 20％似乎是一个合理的比例，开发人员应该更多地注意使其正常工作。 如果您正在为需要对视图进行100％特殊处理的项目工作，则切勿使用它。 但是同样有80％的开发人员可能不在这个位置。

另一方面，开发人员的技能水平是另一个因素。 我的同事将按原样编写代码，即： 边框宽度，边框颜色，字体大小，文本颜色，addSubview…等； 并为下一个组件重复所有操作。 因此，当您查看自定义视图时，您会看到每10条线设置了拐角半径，没有人去创建RoundButton并从那里去。

不不不。 更快，更轻松，更诱人。

谢谢尤达大师。 我会更快更轻松。

在当前的项目（由3到4个人组成）中，我完成了80％的UI和与UI相关的API。 当然，没有更多的上下文，这个数字毫无意义。

但是我可以告诉您的是，如果您打算编写UI代码，请确保可以至少以与故事板相同的速度来执行。 因为速度很快 。 您不会看到Apple促进您编写更多的UI代码，并不会在以后的Xcode版本中帮助您做到这一点。 苹果希望您使用情节提要，并努力对其进行改进。

这并不意味着当视图很特殊并且无法使用情节提要时我会碰壁。 我只是换了个齿轮，编写了很棒的基于代码的自定义视图，然后继续前进。 这一切的核心是情节提要板在处理简单视图方面确实非常快，因此我不必花时间在代码中进行设置。 我可以看到结果，在设计时解决了所有自动布局问题； 通过使用情节提要引用，我可以将情节提要文件保留在原子卷中，因此几乎没有合并冲突。 如果确实发生这种情况，则只需使用两个版本中的一个，而无需真正解决冲突。

看到一个团队开始避免与情节提要相关的合并冲突而感到尴尬，并看到它花费了两倍的时间和十倍的UI代码，（并且因为花费了很多时间，所以没有时间编写测试）然后听到它声称情节提要对团队合作不利。

坚持不懈地进行所有工作，因为显然我不在一支经验丰富的精英开发团队中。 我在一个使故事板看起来不错的团队中。

但是另一方面，如果您身处第三世界的自杀小队，并且计划进行最少的协调和架构工作，