当然，如果最终合并结果正确可信，那么很多同学还是可以忍受的。然而，

合并毕竟是会出问题的，尤其是用

Git 自动合并。这些问题直到运行时才会出现！

倘使测试力度不够，这就是潜在的隐患。此外，我们知道

NIB 是人不可读的，

也就是说，对它做版本控制几乎没有意义。你没法从

diff 看出来半点名堂。倘使

你使用的不是

NIB，而是一行一行的 Objective-C 代码，那么结果会好很多。

选择显式而非隐式

我 喜 欢 用 代 码 来 完 成 各 种 东 西 ， 这 样 你 打 开 一 个

view 或 者 一 个 view 

controller，就能看到所有东西。否则，看你代码的这位同学还得去找相应的

NIB。

NIB 同样也是滋生 bug 的温床，很多时候你调试了半天才发现，某个 bug 并

不是出在自己的代码里，而是在

Interface Builder 的某个小角落里自己忘记给某

个选项打上

√。如果所有的组件都由代码生成，那么在调试时就简单得多，你只

要专注于和

View 有关的代码就快好了。选择显式地在代码里写 view，可以让你

对

view 有强大的控制力。从初始化到布局、绘制你都能插手，在代码里你清楚地

知道某个

view 的各个属性会是多少，而非交由 Interface Builder 来管理，这样虽

然看上去代码行数多了，但它帮你减少了

bug 数量，节省了 debug 时间。

耦合

用

Interface Builder 去创建可复用的 view 会是一件很蛋疼的事。首先你需要

拖拽出各种各样的组件，然后给每个组件设置属性，接着你要把

outlet 连接到

要用到的代码块

……某一次，你忘记连 outlet，然后你的程序就在 runtime crash

了。看，你又弄出了一堆

bug。对于各种 零碎的 view 我更喜欢为他们写类，然

后在里面实现各种我想要的东西，在需要用到这些

view 的时候生成对象就是了。

如果我有什么错误，编译器大哥还能帮我检查。