TL; DR
昨年、Rambler＆CoのiOS開発部門は、 VIPERアーキテクチャアプローチを使用するためのすべての指示、ベストプラクティス、およびヒントを収集してきました。 全体としては、いつものように、すべてのコンポーネントの合計よりも大きいことが判明しました。結果は素晴らしい本になりました。 そして今、私たちはその初版を提示する準備が整いました！
ダウンロードリンク
Rambler＆CoのiOS開発部門は、基本的に4人で始まりました。 最初の年に、部門は4倍に成長しました。 1年後、私たちはすでに25歳でした。 並行して、メールアプリケーション、ブログプラットフォームのクライアント、メディアプロジェクトなど、10を超えるプロジェクトを開発しています。 急速な成長段階で解決しなければならなかった最も重要なタスクの1つは、アプリケーション開発アプローチの標準化でした。
この問題の解決策は、 VIPERのようなアーキテクチャ上のアプローチでした。 VIPERは、管理上の問題を解決するのに役立ちました-アーキテクチャに対する統一されたアプローチにより、異なるプロジェクト間で人をシームレスに切り替えて、新しい従業員を簡単に統合でき、プロジェクトの品質を改善するために-高いモジュール性により、モジュールを互いに完全に独立して開発できましたが、コードの残りの部分に影響を与え、 UIViewController
をレイヤーに明確に分解することで、テストでコードのカバレッジを拡大する問題がUIViewController
しました。
もちろん、私たちのプロジェクトへのVIPERの導入は徐々に行われました。 私たちが遭遇した主な問題は、単一の知識ベースと実際的な例の不足でした。 インターネットには、このアプローチの簡単な使用例（認証画面、タスクリスト）がたくさんありました。 これらのアプリケーションは、モジュールのコンポーネントの相互接続の基本原理を簡潔に示しましたが、より複雑な質問「1つのモジュールから別のモジュールへの移行方法」 、 「モジュールの構成の実装方法」 、 「一般的なビジネスロジックの記述場所 」には答えませんでした。
空のニッチはすべて埋められ、具体的にはこのタスクを引き受けることにしました。 毎回、VIPERの質問に直面したとき、私たちは興味のある人々の密接なグループと集まり、激しく議論し、掲示板を書き留め、最終的に共通の決定に至ります。 私たちの紛争の結果は記録されました-そして最終的に、彼らはVIPERと私たちの本の使用に関する一連のレポートに変わりました。
VIPERの本は、条件付きで3つのパート（理論、実用、およびアプリケーション）に分けることができます。
- 理論的な部分では、モジュールの一般的な構造、標準と追加の両方、VIPERの歴史、コード生成の問題、モジュール作成の自動化に焦点を当てています。
- 実用的な部分は、他の情報源が知らないという非常に秘密を明らかにします-画面間の遷移、モジュールを構成するためのさまざまなオプション、テストでコードをカバー、UIWebViewやNSFetchedResultsControllerなどのシステムコンポーネントとのVIPER統合
- また、このアプリケーションには、VIPERモジュールの一部としてのコードスタイルの見方と、問題をさらに理解するための資料の選択が含まれています。
ご覧のとおり、代名詞「we」は記事全体で使用されていますが、これは偶然ではありません。 この本の作成は、1人ではなく、チーム全体と多数の外部貢献者の作業の結果です。 ほとんどすべての章はさまざまな人々によって書かれていますが、モバイルアプリケーションアーキテクチャの構築については共通の見解を持っています。 私たちが提案するすべてのアイデアとアプローチは、数十の多様なアプリケーションでテストされており、ロシアと世界中のチームで使用されています。
VIPERの第1版はGitBookサービスを使用して作成され、複数の形式で同時に利用できます。
さらに、私たちはこの本を他の言語に翻訳することに積極的に取り組んでおり（多くの人にお願いします）、このプロセスの助けに感謝します。
質問、提案、またはタイプミスに気付いた場合は、 Issuesにご連絡ください。