這是一系列以「建構基礎概念」為目標，希望能幫助 Swift 開發者更加瞭解 protocols 和 generics 的文章。文章索引、相關資源以及較詳細的介紹，請見系列簡介。希望讀者在看到文章裡提出問題的時候（請注意 [Q] 標示），能夠一起試著解釋看看，好深化你個人的理解。
上次在 Part 1 裡，我們試著分辨 protocol 和其他的 type 有什麼不一樣。當 protocol 作為 type 使用時，它被稱為 existential type。本篇會假設讀者已經熟悉 Part 1 的內容。
這次的篇幅較長，但是與其拆成數篇，我想把閱讀方式交由讀者自己決定。如果這些對你來說是比較不熟悉的概念，我建議分次分段閱讀，這樣吸收的效果會更好。
如果有人問你這個問題，你會怎麼解釋？[Q]
核心問題：
Protocol as type，也就是 existential type，和 type erasure 之間有什麼關係？
延伸問題：
Type erasure 有什麼替代方案？它們和 type erasure 有什麼性質上的不同？
這是一系列以「建構基礎概念」為目標，希望能幫助 Swift 開發者更加瞭解 protocols 和 generics 的文章。文章索引、相關資源以及較詳細的介紹，請見系列簡介。
希望讀者在看到文章裡提出問題的時候（請注意 [Q] 標示），能夠一起試著解釋看看，好深化你個人的理解。
如果有人問你這個問題，你會怎麼解釋？[Q]
核心問題：
Protocol 作為一個 type，和 enum, struct, class… 等等其他的 type 有什麼不一樣？
延伸問題：
在 Swift 5.6 以後，protocol type 的 variables 前面要加上
any一字。為什麼要改成這樣？
最近我把以前的一個 personal project 挖出來翻新，從中得到了許多奇奇怪怪的開發經驗。趁印象仍深，做點記錄。
對軟體工程師來說，這是個老掉牙的問題：實作一個功能的時候，要先保持簡單，避免 overengineer — 過度設計？還是預先拆設出架構、抽象化，來讓以後擴充功能的時候更順暢省力？
我想，雖然對於什麼是 “clean code” 普遍有各種原則，適當的平衡應該還是要視個人自身的經驗和能力和 project 的特性來拿捏。畢竟什麼東西是容易的，或是能判斷之後一定會用上的，並沒有標準答案。我其實也沒有什麼高見可以教別人，只是遇到了兩個相似的情況，產生了點想法，把它整理出來。
大約 2016 到 2018 年間內，我曾經試著開一堂 iOS Auto Layout 的線上課程。我做為 iOS 開發者的經驗有限，但依著自己的數學背景以及對教育的興趣，那時覺得自己在這方面能做點什麼。
直到現在我仍認為，Auto Layout 中等到進階的知識，在網路上過於欠缺且分散。這世上並不存在一堂我心目中的 Auto Layout 中高階課程。
我閉門錄了些影片，且把課程預定的規模縮編了幾次，但這堂課從未真正上架。在我做了最後一次縮編，覺得可以先上一版時，SwiftUI 問世。綜合一些其它因素，終於不再歹戲拖棚而停手。而這也是幾個月前的事了。
雖說是個丟臉的失敗史，但也不甘就此淡忘。最近終於有些閒，決定來為這整件事稍做紀錄。文底會提供現有影片的連結，歡迎自由取用。
一眨眼，不但心得分享的上半已經是幾個月前的事，連第二屆的 iPlayground 都快要開始了。第一屆的心得再不寫完，別人都要寫第二屆心得了。
事實上，原本要留到後半寫的內容中，有些動筆時才覺得邏輯過於粗糙，所以草稿被我棄置了。只是既然有了「上」，甚至還預告了內容，那不硬擠個「下」出來也太說不過去。所以我想還是來把手邊的舊心得筆記稍做整理，從簡隨意。文句不順之處也請見諒。
大致上主題還是在議程和 secret party 兩者，不過我想既然第二屆即將到來，與其講去年的心得，不如多分享一些個人建議。