工作紀實・第五週結束

第四週因為有黃金週、只有上班兩天,就跳過沒寫了。而自從第三週結束左右, RxSwift 的基本的設計、operator 使用能力就差不多完備,也漸漸不會寫出自己難以找出錯誤的程式碼。

接著給自己很重要的任務就是,讓已經接近定型的設計模式,更加熟練、並在開發日常生活中,多花心思專注領域面的邏輯和流程,盡量降低前置的實作設計不熟悉所衍伸出來的風險。

於是,第四週到第五週的成果基本上都有達成預期的目標,開發的速度也變很快。最主要的就是這項

  • 能夠測試 RxSwift 的 code

能夠測試 RxSwift 的 code

設計模式

這個部分我覺得 RxSwift 有著他相對的優勢,和 Swift 的設計模式相比, RxSwift 的「流」的概念,更把「輸入(input)」和「輸出(output)」(或應該可以說成 functional programming)這個概念,推得更表層、推得更容易被開發者注意到。

雖然現在還沒歸納出我自己比較熟練的的開發方式是什麼,但是大約隱約感覺到這一類的規則:

  • 舉 view model 為例子好了,如果能夠更加清楚(邏輯上以及接口上)了解什麼東西對這個 view model 輸入了、什麼東西輸出了,可能就是比較好的設計模式。
  • 能夠針對輸入或輸出,很方便的模擬傳入的事件、以及驗證輸出的結果。如果能夠達成這樣的特性,我認為可以協助達成「程式碼可測試」的這個目標,因此就會是比較好的設計模式。
  • 能夠利用 DI 的方式注入其他類別物件降低耦合,並可以方便地用 mock object 替換掉。舉例來說,如果某個 view model 需要進行一個 api request ,就必須要可以注入一個 request object 的 mock ,並可透過替換 mock 去測試不同的 response 結果發生的時候,這個 view mode 的「輸出」有沒有如預期般的反應。如果可以不花很多力氣達成這個目的,該部分的程式碼,可能就會是比較好的設計模式。

抽象化

抽象化,也就是這兩年 swift 界一直在講的 protocol oriented 這件事。而如果要達成 DI-able 這件事,向上抽出一層 protocol 的介面層可以說是必要的工作。

而這兩週以來有達到下列這一類的目標,抽象化向來是隔離相依的最好幫手

  • 讓 view model 可以不相依建立在 APIKit 之上的 request objects
  • 讓 view model 可以不相依建立在 Himotoki 之上的 model
  • 讓 view controller 對 view model 不直接相依,而只對 view model 的 protocol 相依。

要能夠達成這些目標,主要會有兩個步驟:

  • 把待測物件有直接相依的物件,向上抽成 protocol ,因此就可以對介面相依、而非對類別相依。
  • 接著,能夠抽成 protocol 之後,設法用 DI 的方式注入這個物件,而注入的型別則是設定為 protocol 。

基本上做了這兩個步驟之後,待測物件內部的程式碼勢必就會需要開始調整。如果比較熟悉的話,就會隱約地注意到,這時候的調整(或說是重構)通常都是會讓程式碼變乾淨以及更好維護。

RxSwift 的測試 Library → RxTest

我目前還沒有用到這個。

目前我的作法就像前面提到的,追求在輸出以及輸入邏輯上清楚、以及可以容易自己打事件進輸入以及容易測試輸出的結果。

因此,基本上就是寫出像是

  • testedViewModel.anInputPublishSubject.on(.next(***))

之類的東西,就可以無痛又很簡單就可以達成打入事件(至少現階段是覺得無痛且簡單)

接著去 subscribe 輸出的接口,去驗證內容即可

成果

目前就結果來說算是滿意的。還有追在 server side API 實作結束上 stage 前、有約定好接口及 response 內容的情形下,在沒真實資料的情形下,先行實作完 app 端的邏輯和測試;在 API 上 stage 後,一接上去就沒有錯誤、如預期般地可以執行預期中的功能。

原本無法測試的程式碼,也提高了一些覆蓋率、也解掉一些原本有耦合的東西,並可以幫助 server side 在完成 API 後,更快速的確認功能沒有問題。雖然做的事情多了一些,可能也有辛苦了一點,但是還滿開心的。


結語

總結來說,這個部分是綜合過去用純 Swift 的設計模式下測試的經歷,再加上 RxSwift 設計模式調整的結果;同時並達成更多 App 端的商業邏輯可以被保護。

因為設計模式基本定型了之後,開發和測試保護的實作速度變快之下,可期望的是在這期 milestone 所訂下的功能,可以更順暢及更沒有錯誤的被實作出來。

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.