[小卓笔记]：使用Storyboard的正确姿式

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

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

不少开发者对于在项目中Storyboard是严格禁止的。SB容易引起冲突，文件的可读性差，加载速度可能更慢都是开发者经常提到的缺点。然而我认为这些是在一些ie使用场景下是能够避免的，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.

欢迎关注个人微博：@没故事的卓同窗