支持純程式碼刻畫面的主要論點
・用 Storyboard 做畫面不容易看到 App 全貌
在 Storyboard 設定樣式看似方便直覺，卻經常會忘記已經改動了哪些部分。反之，全用程式寫則一覽無遺，更別提動態畫面的設計只能用程式完成。
・編譯 Storyboard 的速度很慢
當 Storyboard 和上面的元件越來越多，執行速度會變得很慢。不過學會使用 xib，這個問題的嚴重性會減少一點。
・在開發團隊中，用程式做畫面比較容易解決 merge conflict 問題
反過來說，要解決 Storyboard 的 merge conflict，必須努力解析 Storyboard 底層 XML 的意義，這並不容易。
其他支持說法
・CodeWithChris 大大認為，程式新手或一人作業再考慮 Storyboard。
・Lets Build That App 大大列出十個應該捨棄 Storyboard 的理由。
此外，他經常用一種 Preview-oriented 的開發方法，匯入自己寫的套件，以 SwiftUI 的 Preview 功能去寫 UIKit 程式，我覺得超酷的！
・iOS Academy 大大很愛用純程式的 Frame-based approach。
搭配 UIView extension，像是自定義可計算屬性 width 會回傳 frame.size.width 或是 left 會回傳 frame.origin.x 等等，可以有效減少程式，像是下面這樣：
・Jeremy Xue 大大原本對於純程式刻畫面抱持懷疑的態度，但上手後，會發現與 Storyboard 本質上沒有任何區別，反而用純程式能夠更理解每一件事情的邏輯，因為沒有任何被隱藏的細節。
・Pala 大大提到了轉職 iOS 開發，一些希望能早點知道的事情。
1. 用程式碼刻畫面
2. Swift 與 ObjC 語法
3. 演算法關乎面試成敗Skeletal Storyboards?
Sean Allen 大大提出一種 UI 編排方式，稱之為 “Skeletal Storyboards”，意思是只把 layout 相關的設定交給 Storyboard 處理，留下沒有樣式的骨架，而樣式相關的設定都寫在元件各自的類別之中。
如此一來，就可以享用到 Storyboard 拉 Auto Layout 快速的優勢，也能從程式看出已經改動了哪些元件屬性，詳情可參考影片。
我將上篇文的客製按鈕程式，改用 Skeletal Storyboards 的方法重做一次：
修但幾勒！
我發現 Skeletal Storyboards 作法有些不好的地方：
當元件樣式變多，將要寫很多獨立的 Class，看起來很臃腫。更糟的是，原本透過 viewModel 參數和 init 傳資料進按鈕內的作法也不能用了，變成得在一個一個類別中設定資料。
再來，因為在 Storyboard 不能在按鈕元件內再放元件，若改用 UIView 取代按鈕畫面，連結到 Swift file 的元件類別就不會是 UIButton，而是 UIView。當我們想在按鈕上使用 addTarget 就不意外的失效了，必須改用 UITapGestureRecognizer ⋯⋯。
程式刻畫面小結（不討論 SwiftUI 方法）
- 單獨開發 App，每個方法都可以，用得開心就好。
- 可以另外開一個 Storyboard 試做元件骨架（加上 Auto Layout），很有把握直接用程式刻也不會出錯，可以略過這步。
- 再來是刻畫面，有兩主要途徑：
第一，基於 Frame 的排版。
第二，基於 Auto Layout Constraints 程式的排版，更彈性一點。
