延續昨天的議題惹 XDDD
我自己是這樣覺得啦，這類文章背後隱隱的透露出一種價值觀： 只要一切都是 code 那就簡單多了、舒服多了。
我能理解 RD 這種傾向啦，因為我們 RD 很熟悉程式邏輯，看到 code 就覺得很親切阿。但是我還是要提同樣的問題，對程式人來說親切的東西？ 對其他人是不是也同樣親切？對視覺人來說親切嗎？ 他們除了抓著 RD 之外，有辦法可以介入工作流程嗎？(如果只是想把字調大一點，或者修正翻譯拼錯字) 拒絕不懂程式的人插手的態度，是不是一種 RD 的傲慢？
我知道這其中有許多細節值得討論啦，像是有人擔心 Artist 會把 xib 改壞。但是在我們公司這是可安排的工作流程，而不是絕對的好與壞。可以教育 Artist 怎麼用 UI design tool 才不會干擾到 RD 阿，可以告訴他們盡量不要去動連接好的 IBOutlet ，不要隨意改元件名稱等等。我很感謝我們公司的 Artist 他們願意學習 IB，願意參與並分擔 RD 的工作，只要手上有個好工具。
回來說說文章吧。文章的第一點叫做：「Choosing Explicit over Implicit」我一看到就笑了XDDD 因為他一開始就假設：用 code 寫的東西叫做 Explicit ，放在 nib 裡面的叫做 Implicit 。那像我們團隊是不是就常常找不到出問題的元件? 可是因為我們團隊早就協議好全部的 UI 都用 xib 做，所以我們第一時間就會檢查 xib ，xib 命名也都有規範，所以很容易找。
我的經驗是用了 xib 有助於團隊把 code 放到對的地方，因為 RD 不會因為方便，就把處裡事務的邏輯跟視覺排版混在一起，比較容易切合 MVC 的精神。
文章第二點，說忘記連接 IBOutlet 會導致 runtime crash，"This is terrible!" ，自動測試跟 assert 就能馬上找出的小問題，足以成為不用 IB 的理由嗎？ 要不要說物件忘了 new 所以會 runtime crash 好可怕XDDD
我想說這這些都是透過工作規範可以避免的啦。兩個人改到同一個 xib，如果 xib 粒度切的夠明確，工作責任的分配導致兩個人必須要修改同一個 view ，工作開始之前兩個人應該先協商一下吧？ 我也很討厭 merge xml。
最後我要澄清我沒有反對手寫 layout，當情況真的有點複雜，還是要手寫 layout 啦。但是我認為斷定 design tool 好不好用的時候，不要犯了完美主義謬誤： IB 沒辦法 100% 解決 Layout 的問題 = 推論出你不該用 IB。
我的經驗是 IB 在 90% 的狀況下讓我排版更輕鬆，從手寫 code 排版的繁瑣手續中解放出來。只要特別處理剩下的 10% 就好了。
當 Controller 裡面只寫事務邏輯，沒有任何 UI 外觀的 code 的時候很清爽不是嗎? 對吧對吧