見出し画像

iOSDC Japan 2021に参加して来ました

iOSDC Japan 2021(以降: iOSDC)に今年も参加。REALITYのiOSチームで課題となっているマルチモジュール化や、それに関連した取り組みに関するセッションに参加してきたので、REALITYのiOSアプリでどのような改善に繋げていけそうかについてまとめたいと思います。

概要

今年も楽しいiOSDCが終わってしまいましたね。かむいです。

REALITYのiOSチームでは今後の開発メンバー増を想定した、スケーラブルに開発を進めていくための取り組みについて模索中です。そのノウハウのオアシスでもあるiOSDCに今年も参加し、我々の技術課題とマッチしたセッションを主に参加して来ました。
今回は参加した中から3つのセッションの感想をまとめつつ、個人的に良い思ったポイントと合わせてまとめていきたいと思います。

大規模リファクタリングの極意

タクシー配車サービスアプリ『GO』のエンジニアである@kamekitiさんのセッション。もともと別のサービスとして運用していたアプリをリニューアルし、既存設計をリファクタリング・リアーキテクチャしたノウハウについての発表でした。
特定のclassの肥大化、技術的負債に対応する時間の悩みなどが共感できる課題でした。
また取り組みについて5W1Hで章がまとめられており、説明の構成も参考になりました。


個人的に良いなと思ったのが「解消すべき技術負債は何か」という問題について、効果の大小/難易度の2軸で考えるグラフが理解しやすく、そこから「計画を立てて本腰を入れてやる必要がある所」「適宜対応していくべき所」「今すぐやる所(けど現実には1つもなかった所)」「後回しで良い所」と整理されているのは納得のいくものでした。

その中でチームメンバーと話し合い、優先度が高かったルーティング処理を取り掛かる際にアプリ全体の設計を見直す必要があり、結果的にRIBsをアーキテクチャとして採用したとのことです。

この発表を通して参考になった点は以下の2点です。

1.  チームメンバー内で設計思想を統一する
2. リファクタリングのためのリファクタリングを行う

1つ目は全体に影響を与えるリファクタリングの対応はチームの協力が不可欠であり、そのための事前準備をしっかり行うことを強調されていました。このプロダクトではサービス統合によりエンジニア数が激増したことも背景として伝えており、プロダクト事情も絡めた優先課題として挙げている点が良かったです。

2つ目は実際にリファクタリングする前の既存コードの見直すべき点や対処法についてまとめられており、特に無駄なコードを自動検知する仕組みとしてDangerを使った静的解析を採用した点は興味深かったです。OSSとして公開されていたため、我々も使ってみたいと思いました。


大規模なアプリのマルチモジュール構成

Cookpadの@giginetさんのセッション。2年ほど前から取り組まれている大規模なマルチモジュール化・リファクタリングについての発表でした。

我々のマルチモジュール化を行いたい理由は、複数並行機能開発の効率化によりチームのスケーラビリティを担保したいというものですが、Cookpadさんは主にビルド時間の短縮を目的としていたそうです。

取り組んだ結果、様々な副次効果が生まれ、その一つに必要最低限の依存関係で構成されたFeature単位のミニアプリを作ることも可能となったそうです。こちらは別のセッションで発表も行われていました。ここでは紹介だけに留めますが、もし興味のある方はご覧になってみてください。

アプリケーションをどのように分割するかという点で、機能単位の分離(縦割り)を試みた結果、1Feature単位のビルドを実現することができ、一方で依存解決しつつ分離が難しい点を説明していました(Feature間は依存を持たない構造にしたため)。

この解決策についてはEnvironmentというプロトコルを用意し、通信や画面遷移といった外部とのI/Oが発生する情報を外部から注入する形で対応していました。これにより該当部分の機能はStubbableなものに変換が可能となり、ミニアプリで画面遷移を行う際は他Featureに属する画面はモック画面を表示する形に出来たそうです。

この発表を通して参考になった点は以下の3点です。

1. 目標値を定期計測・視覚化する
2. 全て一度に移行せず、古い実装は隠蔽できるインターフェースを用意する
3. コード生成機などを用意し簡単にモジュール生成できる仕組みを用意する

1つ目はモジュールをどの程度分割できたかをダッシュボードで閲覧できるようにしていました。これは指標を定期的に確認するには良い取り組みだと思いました。

2つ目は古い実装を移行しなくても、新規実装のみをモジュール分離できるように意識して設計するのが寛容であり、古い実装(シングルトン等)は隠蔽できるインターフェースを用意すると良いという話がありました。

これはREALITY iOSでも導入を進めている新たなDIの仕組みで行なっており、中長期的に取り組み対応としてはその通りだよなと腑に落ちたのが良かったです。
REALITY iOS新たなDIの仕組みについてはこちらの記事をご覧ください。

3つ目はボイラープレートの自動生成について、GenesisなどのOSSも活用しているとのことでしたが、特にXcodeGenのTarget Templates機能を使った、柔軟にTargetを増やせる仕組みは我々も早速使いたいと思いました。
XcodeGenのコミッターでもあるgiginetさんならではのOutputでもありますが、REALITYのiOSでも利用しているOSSなので、Documentを今一度おさらいしようと思いました。



iOSエンジニアがKMPで大規模アプリのロジック共有化をしてうまくできている話

ホットペッパーグルメアプリの@nirazoさんのセッション。Kotlin Multiplatform Project(通称: KMP) を用いてiOS/Android両プラットフォームで利用できるビジネスロジックコードを用意し、コードの共通化を行うことで開発効率を高められているという話でした。

iOSでは基本的にはSwiftを使ったコーディングとなりますが、そこにAndroid開発で使われている言語や環境を用いてビジネスロジック側のコードを共通化するというのは最近耳にするお話だったので、iOSエンジニア視点での体験談はとても参考になりました。

ホットペッパーグルメさんでのチーム構成が以下のような形となっており、KMPを用いたビジネスロジックまわりを担当するチームが用意されているようです。

実際にどの程度共通化ができているかというのを数値でまとめており、現状99%実現ができているとのことでした(共通化できないものは無理に共通化しないという方針とのこと。またinterfaceを提供しているライブラリの数も影響しているとか。)

実際にKMPを用いた体験談については翌日Wantedlyさんが発表されていた『KMMを使って感じたPros/Cons』でも話されており、こちらも合わせて参考にしてみるとKMPの知見が得られると思います。

この発表を通して参考になった点は以下の2点です。

1. KMPを使った際にぶつかったiOSエンジニア視点での課題と対処法
2. REALITYで採用する際の可能性について

1つ目について、まだREALITYでは採用していない技術だったので参考程度となってしまいましたが、2つ目について考えてみました。

現在REALITYのNative AppチームはiOS/Android両Platformで1チームとしており、互いの距離感も近いのでKMPが選択肢としてあるのは良いかもと思いました。
KotlinはSwiftと似ている点が多い言語というメリットはありつつも、gradleの理解に苦しみそうだなという懸念はありました。しかしAndroidチームといかに連携して進められるかという点をセッションでも話されていたので、その点について我々は解決できそうだなと思えるのが好印象でした。

まとめ

他にも参加したセッションはありましたが、今回はREALITY iOSチームの技術課題に当てはまるものを中心にまとめてみました。

iOSDCは毎年スポンサー紹介動画が注目されていますが、今年は新たに声優・立木文彦さんによる各セッション名・登壇者名の読み上げがあり驚きました。(エヴァンゲリオン繋がりでミサトさん・シンジと来たのでゲンドウかと思ったら喋り口調は世界の果てまでイッテQでしたが笑)

例年通りであればYoutubeにセッション動画が公開されると思うので、まだ聞いたことが無い方は是非聞いて頂きたいです。「自分もCfP出して採用されて、立木さんに名前を呼んでもらいたい!」と思わせるインパクトがありました。


来年こそは私もREALITYの技術課題の対応で得られた知見を基に、CfPを出して登壇できるように頑張りたいと思いました。

REALITYではプロダクトのリファクタリング・リライトが好きなエンジニアを募集しています。 
ちなみにこれらの改善施策は、新規機能開発と並行でよしなに個々人で頑張ってねーではなく、きちんと改善施策のための時間が用意されています。
もし興味のある方は、meetyでカジュアルにエンジニアとお話ししてみませんか?お待ちしておりますーmm