內容來自 SwiftBySundell 的廣播節目第20期
這次的特別來賓是 Radek Pietruszewski
software writer at Nozbe and creator of SwiftyUserDefaults
他說自己是 software writer 而不是什麼厲害的架構是，因為他不認為自己真的弄了什麼厲害的架構，而只是認為自己寫的程式碼是讓人讀的，所以稱自己為 writer 。
以下條列幾個重點
- 從 Requirement 到 Solution 的能力就是 Senior developer 該具備的能力
- 每個人都應該去看看 Functional programming 跟 ReactNative ，即便你不去真正使用它，你也會從中得到很多不同靈感，在未來面對其他問題時會很有幫助
- 尤其強調 ReatNative 是未來 update state and UI changed
function(input, state) - 依賴注入(Dependency Injection)不過是把一個物件傳給另一個物件，不是什麼多困難的事情
- 在軟體開發必須為未來考慮，因為隨著時間過去 spec 會改變，設計會改變，必須為未來準備
- 用 Default 取代 Singleton ，用 Factory 輔助
- 像是現在流行的 Micro service 一樣，我們可以用 Micro features 來因應複雜的需求，像是拆分成 framework (但推薦 static framework, 因為 dynamic framework 會有 app launch time 的問題)
Obj-C to Swfit 的建議
他沒有太多這樣的經驗，但不建議重寫，因為重寫總是會有很多風險而且花的時間通常超過你的預期。最終可能會變成從已知的 bug 換成未知的 bug 而已。
建議從 Testing 跟新功能開始寫 Swift，熟悉語法同時練習哪些元件可以拆分出來。
DI and singleton
依賴注入(Dependency Injection)不過是把一個物件傳給另一個物件，不是什麼多困難的事情，只不過是養成良好的習慣。
如果只是一個人做的小 project 是沒差， singleton 不會是什麼問題。
但如果你要做的是產品，一年以上的產品，你必須要跟很多人合作。也因為時間拉長的關係隨著時間過去 spec 會改變，設計會改變，你原本的假設會被破壞，原本你認為只會有一個 instance 的假設不存在了，這時 singleton 已經散佈在 100 多個地方，你就會超級難改。
在這樣的情境下寫出容易修改，容易維護的程式碼，就是維持高品質程式碼的關鍵。
如果你有好一點的架構，就不需要花一個月只為了一個假設被改變了。
我們雖然不能預知未來，但能夠為它做準備。
Sundell 則是說自己常用 Default argument 避免使用 Singleton (詳見 avoding singleton)，另一個他常用的手法是用 Factory pattern 可以一行建立 instance 來避免使用 Singleton。
No Comments