PayUはMVVMアーキテクチャでコードのテスト容易性をどのように向上させるか:- www.deekpay.com

この記事では、PayUがどのようにアプリケーションとSDKをMVVMアーキテクチャに移行し、コードのテスト可能性、拡張性、可読性を向上させたかを説明します。過去数年間、当社はユーザー・インターフェース（UI）のアップデートを何度か繰り返してきましたが、コアとなるビジネス・ロジックは（新機能を除いて）ほとんど変わっていませんでした。しかし、オリジナルのアーキテクチャでは、ビジネスの成長に必要なアップデートのペースに追いつくことが困難でした。そこで私たちは、MVVMアーキテクチャを採用することで、コードをより読みやすく、スケーラブルで、テストしやすいものにするため、基盤となるアーキテクチャの再設計に注力しました。

以前は何をしていたのか？

それまでは、MVCパターンに従っていました。理論的には、このパターンは私たちにとってうまく機能しているように思えたが、コードベースが大きくなり、UIの反復が増えるにつれて、2つの理由からコードベースが管理できなくなることに気づいた：

UIを繰り返すたびに、UIコードだけでなくビジネス・ロジックも変更している。これは、UIがビジネス・ロジックから完全に分離されていないことを端的に示している。

コード・ベースが拡大するにつれて、ユニット・テスト・コードの量は減っていく。これは、テストピラミッドがひっくり返るという悪い兆候だ。

私たちは間違った方向（左から右）に進んでいる。

この問題を理解しようとすると、ViewもControllerもModelに依存していることに気づく。さらに、アクティビティとフラグメントには、UIロジックとコントローラロジックの両方が含まれている。その結果、単体テストのコード量が減り、コードが管理できなくなる。

MVCアーキテクチャ

MVVMアーキテクチャの償還

私たちはより良いアーキテクチャを探し始め、MVVMが私たちの救いとなったのです。GoogleでさえMVVMを支持した。

MVVMはModel-View-View Modelの略である：

モデル：アプリケーションのデータレイヤーを表す。

View：アプリケーションのUIロジックを表す。

ViewModel：ビューのモデル。ビューとモデルの橋渡しの役割を果たし、ビューを直接参照することはありません。

MVVMアーキテクチャは、コンポーネント間の密結合を取り除く。子コンポーネントは親コンポーネントを直接参照せず、観察可能なプロパティを通してのみ参照する。各コンポーネントは、次のレベルのコンポーネントにのみ依存することに注意してください。この設計により、首尾一貫した楽しいユーザーエクスペリエンスが生まれます。

上の図でもう1つ重要なコンポーネントはRepositoryモジュールである。これはデータ操作を扱う。アプリケーションの他の部分が簡単にデータを取得できるように、明確なAPIを提供します。どこからデータを取得し、データが更新されたときにどのようなAPIコールを実行する必要があるかを知っています。リポジトリは、永続化モデルやウェブサービス、キャッシュなど、さまざまなデータソース間の仲介役と考えることができます。

LiveDataは、観測可能なデータホルダーです。LiveDataコンポーネントはまた、アクティビティ、フラグメント、サービスなどのアプリケーション コンポーネントのライフサイクル状態を尊重し、オブジェクトのリークや過剰なメモリ消費を防ぐクリーンアップ ロジックを含んでいます。

バンテージ

懸念事項の分離：すべてのコードをアクティビティやフラグメントに書くのはよくある間違いです。UIクラスには、UIとオペレーティング・システム間のインタラクションを処理するロジックだけを含めるべきです。これらのクラスをできるだけシンプルに保つことで、ライフサイクルに関連する多くの問題を避けることができます。MVVMでは、各タイプのクラスが1つのタスクだけを担当するようにすることができます。

テスト容易性：ユーザーインターフェースとインタラクションは、テストケース（Espressoライブラリ）をインストルメント化することでテストできる。ビューモデル(ViewModels)とリポジトリ(Repository)は、JUnitを使用してテストできます。

拡張性：UIのアップデートを簡単に導入できる。既存のコードベースの大部分をリファクタリングしたり変更したりすることなく、新しい機能を追加できます。より簡単にコンポーネントを挿入したり、引っ張ったりできる。

管理性：コードベースはより管理しやすくなっている。すべてのUIロジックは1つの場所に、ビジネスロジックとデータロジックは別の場所に。

欠点

MVVMを使い始め、新しい機能を追加するには、ある程度のパターン経験が必要かもしれない。学習曲線は比較的急です。

MVVMパターンに従うと、より多くのJavaクラスが作成されることになるかもしれない。

結語

どのようなアプリケーションを構築する場合でも、正しいアーキテクチャ・モデルを選択することは非常に重要である。

私たちの場合、MVVMは有用なパターンであることが証明された。なぜなら、私たちはUIリッチな製品を持っており、UIが頻繁に反復更新されるからである。私たちは、製品のテスト可能性に焦点を当てたいと考えており、懸念事項の分離を達成したいと考えた！