iT邦幫忙

2018 iT 邦幫忙鐵人賽
DAY 27
1

人能自律,但前提是有法律,同理,軟體架構和 Style Guide 就是程式中的法律,不從者,該死愛的小手。

Style Guide

Ray Wenderlich - Swift Style Guide

https://github.com/raywenderlich/swift-style-guide#extending-lifetime

這篇涵蓋了大部分 Swift 開發過程中,會遇到的 Style 選擇時機,而且其最終選擇都很理性,也因此是一個客觀、適合盲從的 Style Guide。

Naming

關於 Naming 的部分,Ray Wenderlich 有寫明,我們應該參考 Swift API Design Guidelines,我的想法是,既來之則安之,既然選擇 Swift 程式語言,在合理的情況下,就遵從 Swift 本身的設計。

但是其中有一點我覺得不合理,在 Ray Wenderlich 的 Style Guide 中,有寫到:

Each extension should be set off with a // MARK: - comment to keep things well-organized.

我認為要能夠快速定位每個物件,是 IDE 的工作,尤其是在型別如此清楚的程式語言下,IDE 應該更容易做到這件事,我們就不用在一一去寫 //MARK: - 協助定位,工程師的腦袋是記不住東西的,不能要求工程師寫程式的同時還要記得寫這樣的註解。

Spacing

Ray Wenderlich 選擇了兩個空白,如果在 Swift 語法每個都熱熱等的狀況下,選擇用兩個空白很合理。

Ray Wenderlich - Swift Style Guide 小結

此 Style Guide 不止提供一個程式碼的「樣式」參考,也涵蓋了很多程式設計上的「最佳實踐」,我認為這樣的 Style Guide 是相當客觀理性,不是隨便遵從一個人的喜好而產生的,因此這個 Style Guide 可以列入考慮。

GitHub - Swift Style Guide

這個 Style Guide 已經在 2017-11-09 結束營業,已經停止維護的話,就不列入考慮,但是我們可以稍微閱讀一下,鑑往知來。

Swift API Design Guidelines

三大法條造就今天的 Swift:

  1. 一個 API 只會出生一次,但是被使用無數次,所以任何 API 的誕生,都是要依照使用的情況而設計。
  2. 清晰的 API 遠勝於簡潔的 API,一段程式碼的簡潔,並不是來自縮短一兩個字的結果。
  3. 為每個 API 寫下「文件式」的註解,如果沒辦法用清晰簡短的語言描述該 API,代表你可能設計出了一個人神共憤的 API。

以上主要來自 Swift API Guidelines 並加上個人習慣用語。

其實三大法條已經能清晰闡述 Swift 的設計理念,下列則是一些相對有趣、特別的 Guidelines。

Naming

  1. Factory Method 一律用 make 開頭,如:x.makeIterator()
  2. 沒有邊際效應的 API 需為名詞,反之則為動詞。
  3. Mutating/non-mutating 的方法需成雙成對,不可單飛。

Conventions

  1. Computed Property 如果時間複雜度不為常數,要特別在註解中寫明。
  2. 轉型用的初始化函式可以忽略第一個參數的外部名稱。

Swift API Design Guidelines 小結

入了王朝,能不祀奉國王?

Architecture

有了律法,就能建構王朝,而王朝的成敗,取決於宮殿的規劃,千萬不能把國王的寢室放在茅廁的旁邊。

https://medium.com/ios-os-x-development/ios-architecture-patterns-ecba4c38de52

大致上看完作者對於各框架(MVC、MVP、MVVM、VIPER)的分析與看法,作者的角度很客觀,總結的部分觀念也很正確,沒有「正確的框架」,只有「最適合的框架」。

由作者文章看起來,VIPER 似乎是彈性最高的架構,但是對於剛起步的小專案來說,VIPER 反而過於複雜,為了達到 VIPER 的設計,反而拖慢了開發速度,因此我認為,在套用軟體框架時,應該針對當下的程式碼做評估,並「適當」地將未來功能加入考量。

因此,從這將近三十天積極開發 Money Mom 的經驗來看,我認為現階段使用 MVVM 最適合。

不用 VIPER 的原因,是因為目前還沒有複雜的使用路徑,整個架構、功能很單純,複雜的是各項界面上的小元件互動。所以應該思考如何讓各個小元件之間,彼此獨立,不要有過度的相依性,並減少程式碼的重複,就能有效改善目前的程式碼,並繼續推進功能開發。

總結

最後評估一下,其實基本上 Style Guide 的部分就暫時依照 Ray Wenderlich、Swift API Guidelines 走,在軟體架構上,則是依照 MVVM 的心法做一些調整,最終的目的都是一樣的,就是讓目前的程式碼更易讀、更好維護、更好開發功能。

其實在網路上搜尋 iOS best practice 之類的關鍵字,就會出現很多常見的「名詞」,比方說各種架構、奇技淫巧、經驗談,這類的文章在各個語言都會出現,不過我在學習新的工具時,還是會瞭解一下,畢竟每個工具都會有各自「習慣」。

最重要的是,不管學習工具還是閱讀論文,要想辦法學到「心法」,也就是要瞭解「為什麼」,為什麼要用 MVP?為什麼要 VIPER?為什麼……?

因為每篇文章,都有一個「背景」,不是每個人遇到的問題都一模一樣,因此我們要學習其心法,然後透過這樣的「心法」基礎,去瞭解、嘗試解決我們所遇到的問題,才不會淪為工具人,被工具利用。

參考資料:


上一篇
Money Mom - v0.2.0 上架前功能修改意外順利
下一篇
Money Mom - 補齊專案基本文件
系列文
iOS 三十天上架記帳 APP30

1 則留言

0
zdey
iT邦新手 5 級 ‧ 2018-01-15 17:08:21

才不會淪為工具人,被工具利用。shavenking

等等,工具人好像不是這樣,就像你平常那樣。
共勉之。

我要留言

立即登入留言