本文的內(nèi)容是對(duì)這篇文章的閱讀總結(jié)
原文鏈接：A Case For Using Storyboards on iOS

顯然王巍的這篇文章里的實(shí)踐經(jīng)驗(yàn)比本文原作者的觀點(diǎn)更加值得認(rèn)可：再看關(guān)于 Storyboard 的一些爭論

很多開發(fā)者對(duì)于在項(xiàng)目中Storyboard是嚴(yán)格禁止的。SB容易引發(fā)沖突，文件的可讀性差，加載速度可能更慢都是開發(fā)者常常提到的缺點(diǎn)。然而我認(rèn)為這些是在一些使用場景下是可以避免的，SB在項(xiàng)目中依然有適用的地方。

使用SB的好處

直觀！

• 可以直接看到界面的視覺效果
• 添加AutoLayout時(shí)更加符合直覺

在SB中的操作可以馬上展示到眼前。使用體驗(yàn)很好，也提高了效率。

如何正確的使用

一個(gè)SB中只有一個(gè)VC！

這樣就減少了沖突的可能，兩個(gè)開發(fā)者同時(shí)修改一個(gè)VC的概率很低，就算沖突了也只是一個(gè)VC較容易解決。

這種方式也為更便捷的從SB中初始化VC提供了一種方式。直接根據(jù)類名載入SB中的 initial view controller 就可以了。不需要給每個(gè)VC指定標(biāo)識(shí)符。

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

不要使用segue

segue的跳轉(zhuǎn)非常不靈活,如果都在prepare中處理數(shù)據(jù)也非常死板。所以不要使用segue跳轉(zhuǎn)。

  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?) {
  ///
}

控件的屬性在代碼中設(shè)置

比如 font 或者 color ，如果直接在 SB 中只能設(shè)置一個(gè)固定的值，建議還是通過代碼使用常量設(shè)置，可以方便的控制全局的控件的樣式。
如果要通過一些關(guān)鍵字查找屬性設(shè)置，在代碼中也比在SB中更容易被查找到。

技術(shù)是死的，人是活的

不要因?yàn)槟硞€(gè)技術(shù)有一些缺點(diǎn)就一棍子打死。并不是有缺點(diǎn)就要全盤放棄。不要給自己這種限制，在合適的場景你依然應(yīng)該考慮使用這項(xiàng)技術(shù)。
原文：

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.

歡迎關(guān)注我的微博：@沒故事的卓同學(xué)