17日目です!本記事はプロダクトのコードをRxSwiftをうまく活用しながらVIPERの設計に置き換えていった話です。置き換えたのか現在、Polcaをリリースをして一年が立ちました。開発をし始めて二年は経過しました。自分はリリースして半年が経過しているときに入社したのですが、当初もある程度機能はある状態で、コード量も1万に突破していく頃でした。自分は開発していく上で下記の問題を抱くようになりました。責務がいたるところに分散しているコード量がある程度多くなってきたテストが書きにくいRxSwiftが既に導入されているのでもっと活用したい。そこで、今後開発をしていく上である程度運用しやすい状態にしたい、変えるタイミングとしては今がやりやすいと考え、VIPERの導入に踏み切りました。VIPERとはそもそもVIPERとはどんなものでしょうか簡単におさらいしていきます。VIPERはiOSにおけるクリーンアーキテクチャの手法の一つとなり、責務を大きく5つに分けています。まとめると以下の通り。詳細はこちらを参照してくださいどのようにしていったかpolcaではVIPERを意識した設計を導入していますが、全てを適用したわけではありません。Routingの部分はまだ適用していません。必要に迫られたとしてこれは、後からでもリファクタリングが可能だと思ったからです。実装編ではどのように実装していったか。Presenterを軸にインターフェースなる部分を作成していきました。ここでは、それぞれの役割が何を伝えて、何を受け取るのかを定義していきます。ここから始めています。その後、Presenterを実装しつつ、Interactor、Viewと実装していっています。別レイヤーのやりとりでは、基本的にはRxSwiftを利用しています。情報の取得時にはSingle<PaginationResponse<ProjectPickup.Project>>を利用し、状況に応じて型を変更して流れを変化させています。}}一覧を表示する時の情報受け渡しは以下のように実装しています。}}InteractorInteractorではEntityをPresenterに渡すロジックが実装されています。ここでは複数Entityに関連したビジネスロジックが含まれており、何を取得して、返すかを決める。UIから完全に分離されます。(なのでInteractorに関連する実装でUI系のframeworkが入っていると設計を考えるがあるかもしれません。}}本来は、Providerを利用して情報を返すときには情報をどのように取得したかはここで隠蔽させること(どのように取得したかは意識させない)が責務にしています。情報を取得するときは現状は、ほとんどネットワークを介して情報を取得することが多いのでシンプルな設計になっています。情報を取得する必要がある場合はここで隠蔽すると良さそうです。以下にProviderの実際の処理が実装されています。PolcaではMoyaという通信処理を抽象化したライブラリを使っていて通信処理を実装しています。}}EntityEntityはそこまでこだわりのある実装はしていません。Viewがその情報を表示させやすいようにデータ構造作ってあげています。基本はDBの構造になっているものがほとんどです。}ViewViewではPresenterから受け取った情報・イベントをどのようにしてそれぞれのUIコンポーネントに伝えるかという実装と、Presenterで必要なイベント(どのタイミングで情報取得してもらうのか)という実装をしています。行なっていることとしては以下になります。Presenterから何かを受け取った初期ロード時に取得した情報を表示させるページングした時に取得した情報を表示させるリロードが行われた時に取得した情報を表示させるPresenterへイベントを伝えるリストの最後まで来たリロードされた初期ロード時このロジックをRxSwiftを利用して表現すると情報の流れを段階的に記述していけるので実装しやすく、コードの見通しが良くなります。}}まとめ実のところ、現状のサービスの規模・フェーズを考えるとまだ早いように思うことがありましたが、自分もこのタイミングでこれは過剰かと最初は多少不安に感じるものはありましたが運用してみてよかったと思っています。よかったところ責務の把握がしやすくなったどこに何が実装されているのか段階をおって把握することができる。テストが書きやすくなったロジックテストだけではなく、ユーザの操作などで変化する状態のテストもかけるようになった課題テストの量が全体としてまだまだ少ない。確実に描いて行ける状況にはなったこれはスピードとのバランスもあるのでどのくらいのバランスでテスト実装していくのかは今後の課題ファイルつくるのが現状だと手作業で自動化されていないするぞ!!ある程度、時間の経過に伴い、サービスの仕様やコードの量は次第に多くなっていきます。僕らは本当に小さいチームでサービスを開発しています。単純にモバイルの仕様だけじゃなくサーバサイドやデザインに関してもいろいろな知識を保持していかなければいけません。実装をその場かぎりのものとして実装してしまうと、数日たてばどういう仕様なのか影響範囲はどの程度なのかを把握しにくくなってしまいます。今では、サービスのコード量は2倍になり影響範囲も以前よりも考えていかなければいかなくなったと言えるので、導入したタイミングとしてはよかったのか思っています。現状、まだまだ発展途中で課題はたくさんありますが、導入してよかったと感じる部分もあるので今後はこれをベースにしてどのようにして運用していくか考え、地道に改善していければと思います。