本文的内容是对这篇文章的阅读总结
原文链接：A Case For Using Storyboards on iOS

显然王巍的这篇文章里的实践经验比本文原作者的观点更加值得认可：再看关于 Storyboard 的一些争论

很多开发者对于在项目中Storyboard是严格禁止的。SB容易引发冲突，文件的可读性差，加载速度可能更慢都是开发者常常提到的缺点。然而我认为这些是在一些使用场景下是可以避免的，SB在项目中依然有适用的地方。

使用SB的好处

直观！

• 可以直接看到界面的视觉效果
• 添加AutoLayout时更加符合直觉

在SB中的操作可以马上展示到眼前。使用体验很好，也提高了效率。

如何正确的使用

一个SB中只有一个VC！

这样就减少了冲突的可能，两个开发者同时修改一个VC的概率很低，就算冲突了也只是一个VC较容易解决。

这种方式也为更便捷的从SB中初始化VC提供了一种方式。直接根据类名载入SB中的 initial view controller 就可以了。不需要给每个VC指定标识符。

有很多特性（static TableView）只能在SB中使用，在xib中不支持，都使用了SB后，这些特性也可以在SB中自如的使用。

不要使用segue

segue的跳转非常不灵活,如果都在prepare中处理数据也非常死板。所以不要使用segue跳转。

  func tableView(_ tableView: UITableView, didSelectRowAt indexPath: IndexPath) {
    usernameToSend = usernames[indexPath.row]
    performSegue(withIdentifier: SegueIdentifier.showUserDetails, sender: nil)
  }

 override func prepare(for segue: UIStoryboardSegue, sender: Any?) {
  ///
}

控件的属性在代码中设置

比如 font 或者 color ，如果直接在 SB 中只能设置一个固定的值，建议还是通过代码使用常量设置，可以方便的控制全局的控件的样式。
如果要通过一些关键字查找属性设置，在代码中也比在SB中更容易被查找到。

技术是死的，人是活的

不要因为某个技术有一些缺点就一棍子打死。并不是有缺点就要全盘放弃。不要给自己这种限制，在合适的场景你依然应该考虑使用这项技术。
原文：

My point is to not disregard a whole technology because you don’t like one aspect of it. You are free to pick and choose which parts you want to use. It’s not all or nothing.

欢迎关注我的微博：@没故事的卓同学