こんにちは。LINEアプリの公式アカウント開発を担当している諏訪と楊です。この記事では、LINE Appの開発を進める上でAndroidの開発者のリソース問題を解決するため、iOSエンジニアがAndroid開発を学習し、実際に開発を始めるまでの過程や学習内容、実務内容などを紹介します。
開発を始めるにあたって
上記はLINEクライアントチームのAndroidエンジニアとiOSエンジニアの当時の人口比率です。
LINEクライアントチームではiOSエンジニアと比べるとAndroidエンジ ニアが少なく、LINEクライアント開発者全体の開発リソース比率の懸念がある一方で、LINEアプリはiOS/Android同時に同様のスペックで開発を行うことが求められており、機能リリースをスムーズに進行するためにも、このギャップの改善が組織としての目標でもありました。この状況は、我々のチームでも同様に影響があり、偏ったリソース配分になっていました。
そこでiOSエンジニアの楊さんにAndroidの開発にチャレンジしてみないかという相談をし、話し合いののち開発を行うための準備を進めました。またLINE Appの中の機能には、さまざまな背景によりiOSとAndroidで細かい部分での処理の違いなど、把握が難しい差異なども存在するため、両方のコードを理解し観察することで、それらの問題の発見や改善につなげることも目的としています。
学習内容
基本方針について
ここでは実際にAndroid開発を始めるにあたり、学習に用いたリソースについて紹介を行います。
基本方針ですが、まずLINE Appでは歴史的な経緯などにより、必ずしもすべての箇所で最新のArchitectureに準拠しているわけではなく、例えば当時は多くの場所でAndroid View（XMLによるUI構築）が利用されていました。そのため、この時点ではJetpack Compose関連は重要度低いと考え学習を後回しにしました。
また、ドキュメントについては、基本的にはGoogleの公式的なドキュメントを利用し、英語での利用を推奨しました。これは日本語などの翻訳言語では最新の情報が適用されないケースがあったためです。一方LINE Appプロダクト開発に関連するドキュメントは幸い社内Wikiが整備されているため、社内環境の開発方法や社内ライブラリの利用方法などはそちらを参考するようにしました。
その他、iOSエンジニアが効率的に学習できる方法を優先するようにし、スムーズに業務に入れるような形を目指しました。下記は実際に当時利用した学習リソースです。ただし、現在はGoogleの提供するチュートリアルの内容は変更されていて、Jetpack Composeによる構成がメインとなっています。
Jetpack Composeについては、現在は標準として推奨されている構成なので、基本的にはそのまま公式コースに沿って進めると良いと思います。一方、もしこれからAndroid Viewに関する学習が必要になる場合は、CodeLab（Google Developers Codelab）でAndroid用のXMLレイアウトに関する内容を検索して参考にすることができます。またViewModel、Repository、Coroutine、Lifecycleなどのビジネスロジック関連も、上記と同様に現在は標準コースから外されたため、必要に応じてCodeLabから検索可能です。
Android関連のドキュメント
Android App tutorial
https://developer.android.com/codelabs/basic-android-kotlin-compose-first-app?hl=ja#7
Googleの提供するアプリ開発のチュートリアルです。上述の通り、現在のドキュメントではJetpack Composeによるレイアウトを紹介されていますが、まずはサンプルアプリを動かしてみつつ、実際のアプリがどのような構成で、どのように動いているのかを理解していくことを目指しました。ここでは下記のことを学びました。
- Android Studioのインストール
- Android StudioのUI基本説明
- Android View(XML)によるレイアウト
- 色の変更やinterfaceの追加
- Fragmentの遷移
Modern Android app architecture
https://developer.android.com/courses/pathways/android-architecture?hl=en
次にAndroidの基礎的な構造を学ぶため、Androidの推奨するarchitectureやベストプラクティスを解説しているドキュメントを利用しました。ここではフェーズごとにUIやData layerなどを体系的に学びました。ドキュメントの中にはComposeを利用した部分もありましたが、データフロー部分など必要な箇所を優先して学ぶようにしました。ここで学習した内容は下記です。
- ViewModel
- Flow
- Coroutine lifecycle
基本的に画面構成は、iOSのパーツと似たようなところがあったため、iOSの経験を活かしながら異なる部分に注意しつつコースを進めました。またiOSにある機能で、ドキュメント中では紹介されなかったものについて使い方を調べたりしました。こちらについては後述します。
Sample app for architecture
https://github.com/android/architecture-samples/tree/views
次に比較的コンパクトな構成で、XMLレイアウトによるAndroid architectureを適用したサンプルについて学習をしました。この構成は比較的実際のLINE Appのコードの構成と比較しても参考にできる部分は多いと考えたためです。
その他のAndroid関連の参考資料
またQiitaやSlideShareなどの参考サイトでは既にiOS開発者に向けた両方のOSの比較解説や、Android言語で特有な処理などを解説したドキュメントが公開されており、これらのドキュメントについても参考にさせてもらいました。
SwiftとKotlinはこんなに似てる！比較用チートシートを公開します
https://qiita.com/tamappe/items/64027b87e6ee075e5f51
まさにこれからAndroid学習を行うiOSエンジニアにとって関心のある情報をまとめられている記事です。実際KotlinとSwiftについては類似した箇所も多く、リファレンスとして利用させてもらいました。
【!ってなんだ】KotlinとJava、nullとPlatformType【NullableにNotNull】
https://qiita.com/RyotaMurohoshi/items/5fcc10d04fecd7304556
歴史的な経緯などから、LINE Androidの中ではJavaとKotlinのコードが混在しています。現在はKotlin化も積極的に進められていますが、Javaに関する理解もある程度必要であり、特にnullに関しての取り扱い方はそれぞれで違う部分があり、気をつけなければならない部分の一つです。こちらの記事JavaとKotlinの相互運用におけるnullの取り扱いについての説明をされています。
実コードを利用したKotlinやAndroidに関する学習
学習を行う上で、既存の社内のAndroidのソースコードは非常に良い参考資料になりました。最初の頃は、簡単な画面の実装を参照しながらサンプルコードの作成を進めました。
Swift利用者の視点から見ると、Kotlinは親和性が高くそれほど戸惑うことはありませんでした。基本的にコースを進める中で、分からない書式に対し逐次調べることで、大体問題なく進められました。
開発メンバーからのサポート
定例Meeting, ペアプログラミング
実際にAndroidを学習する中で不明点などを解決するために、週に2回程度のMeetingを設けて進捗の確認や不明点の解決などを行うようにしました。またチームのAndroidエンジニアのTakasyさんにメンターのような役割を担ってもらい、Zoomの画面共有機能を利用しペアプログラミングの形で実際のコーディングを一緒に行ったりすることで学習のサポートを行いました。ペアプロを行う中で、相手の操作を見て質問することでAndroid Studioの操作などを学ぶことができたり、新しいIDEに不慣れな部分を改善していくことができました。
モブプログラミング
今回の取り組みである”iOSエンジニアがAndroidを始める”ことをきっかけに、部内でモブプログラミングを週1回の頻度で開始しました（詳細はTakasyさん執筆のブログを参照）。ペアプロよりもさらに参加者が多くなり、各メンバーの普段の仕事内容を見たり、IDEの使い方や便利なプラグインを共有してもらいました。学習者として、ドライバーをやることで多くの支援を受けることができ、最初は理解できない部分もあり少し苦労しましたが、最終的にはとても勉強になりました。
実務が始まってからは、プルリクエストのレビューや相談などもAndroidメ ンバーが行い、モブプログラミングを利用してコードの改善と提案したり学習ができるようにしました。
社内版ChatGPT
また不明点などは社内版のChatGPTを利用して解決を試みました。ここでサンプルコードを作成してもらったり、実現方法の提案を受けたりしました。また、LINEアプリ内のモダンな記述方法を確認するのにも非常に役立ちました。たまにハルシネーションが発生することもありましたが、確認しながら全体として初心者レベルの学習には全く問題なく利用することができました。
実業務へのアサイン
次に実際に開始した業務についてを書きます。
社内向けライブラリのテストコード追加
最初の仕事として、社内向けライブラリのテストカバレッジを上げるためにテストコードを追加しました。歴史的な経緯から、このライブラリはまだJavaで構成されている部分が多かったため、テストを追加すると同時に、元のJavaクラスをKotlinに変換する作業も進めました。Android StudioのKotlinへの変換機能を利用することで、概ね問題なく書き換えることができましたが、上述のようにKotlinからJavaの関数を呼び出す際に、nullに関する処理には注意が必要でした。
OfficialAccountメッセージ処理のdebug機能追加
こちらはLINEのOfficialAccountメッセージに関する内部的な処理についてのdebug機能です。もともとQAの確認のために用意したこの機能は、iOSでは既に存在していたものの、Androidにはまだ用意していなかったため、Androidをトライし始めたタ イミングとしてちょうど良い機能というところもあり開発に臨みました。テストコードの作業では、学習コースで学んだArchitectureなどの内容をなかなか実践できなかったため、このdebug機能を通じてXMLベースの画面実装を実践できました。 またここで気づいたiOSとの違いもありました。iOSのようにコンパイル時に切り替える#if #endifのような機能がないため、通常はランタイム時に条件分岐でデバッグ機能などを組み込む必要がありましたが、Flavorごとに実現ロジックを変えることができるため、本番環境のバイナリに含まれないようにする方法をチームレビューを通じて理解することができました。
OfficialAccount向け新機能追加開発
次は我々のメイン業務であるOfficialAccount向けの、機能のリリースにむけた開発です。
初めてAndroidメンバーとしてiOSメンバーと一緒に企画と打ち合わせをし開発を進めた案件となりました。iOSの実装を参照しながら開発を進めていたため、QA前の段階でiOSの実装とスペックが合わない部分に気づき、早期に対応することができました。このようにして初めてiOSとAndroidの両方を見ることができるメリットを実感できました。クライアント開発において、こういった両OSの挙動が異なることがあるため、今回のように実装する時点で気づくことができれば、このような不整合が少なくできそうです。
体験して気づいたAndroidとiOSの開発の違い
開発ツールの違い
Android StudioはIntelliJを基にしており、様々なモダンな機能が利用できるので、不便さはなく、Xcodeよりも使いやすいと感じました。XcodeとAndroid Studioの違いは調べれば多くのブログが見つかるので、ここでは個人的に良いところをまとめます。
コードリファクタリング
Renameは開発中に日常的に利用する機能で、Android Studioでは変数名を変更したら左側に関連するところを一括変更するボタンが表示され、押すと関わるところが全て変更されます。Xcodeも似たような機能がありますが、関連箇所を洗い出す際に場合によってはフリーズすることがありました。
プラグインが充実
IntelliJのプラグインが使えるので、拡張性が抜群で、開発スタイルに応じてプラグインを導入できます。
検索
クラスや構造体名、ファイル名による検索が可能です。Xcodeは基本的に全体検索しか利用しないので、これができるのは非常に便利でした。
Function検索
Functionの呼び出し箇所を検索する際に素早く結果が表示され、テストでの利用箇所が色違いで表示されるため、ソースを確認する際に非常に便利です。
変数検索
変数の利用箇所の検索もよく利用される機能で、Android Studioでは変数に値を渡すか、変数の値を利用するかが検索時に異なるアイコンで表示され、検索結果からフィルターをかけることもできます。
デバッグツール
値の観測などが非常に速く、特に大規模なプロジェクトではXcodeとは大きな差があります。
UI構築ツール
主観的なものですが、XcodeのInterface Builderも悪くないですが、あまり構築コードを弄りたくな い場合、Android Studioの方がコードが比較的分かりやすく、コンフリクトもしにくいと感じます。
ファイル構成とディレクトリ構造
iOS
Xcodeでは、プロジェクトは通常、.xcodeprojファイルを中心に構成されています。ソースコード、リソース、設定ファイルは、グループとしてXcode内で管理され、実際のファイルシステムとは異なる場合があります。
Android
Android Studioでは、プロジェクトはGradleを使用したディレクトリ構造で管理されており、.xcodeprojのような特定のプロジェクトファイルは必要ありません。各プロジェクトは複数のモジュールで構成され、各モジュールは独立したビルド設定を持っています。srcディレクトリ内にはmain、test、androidTestなどのフォルダがあり、コードとリソースが整理されています。この構造により、プロジェクトの柔軟性が高まり、異なるビルドバリアントやフレーバーの管理が容易になります。
実行モードとデバッグモード:
iOS
Xcodeでは、基本的にビルドして実行する際にデバッグ情報が含まれますが、特定のデバッグモードを選択することは少ないです。デバッグは主にデバッガを通じて行われます。
Android
Android Studioでは、アプリを実行する際に「Run」モードと「Debug」モードの2つがあります。「Run」モードはアプリを通常の方法で実行し、デバッグ情報を含みません。「Debug」モードは、デバッグ情報を含み、ブレークポイントの設定やステップ実行などのデバッグ操作を可能にします。この2つのモードの切り替えにより、開発者は効率的にアプリの動作を確認し、問題を特定できます。
ファイル並び順
Xcodeプロジェクト
Xcodeでは、プロジェクト内のファイルは通常、.xcodeprojファイルにより管理されます。Xcode内で表示されるファイルのグループは、実際のファイルシステムのディレクトリ構造と一致しないことがあります。ファイルは、ナビゲーションペインでグループとして整理され、開発者はプロジェクトの論理構造に基づいてこれらを組織します。
Android Studio
Project View
プロジェクトビューでは、ファイルとディレクトリが実際のファイルシステムの構造に基づいて表示されます。これは、ファイルの物理的な配置を確認したいときに便利です。
Android View
Androidビューでは、プロジェクトが論理的に整理され、開発者が必要とするリソースやコードに簡単にアクセスできるようにします。たとえば、リソースファイルはresフォルダにまとめられ、Java/Kotlinコードはjavaフォルダに整理されます。このビューは、Android開発に特化した構造を提供し、リソースやコードを効率的に管理するのに役立ちます。
Xcodeとの対比
日常の開発によく使われる機能は以下の図の通りになります。同じ色で囲まれたのは同じ位置付けの機能になります。
振り返り
上記のような流れで、最終的にAndroidの実業務を行うまで成長することができました。その後、我々の中でレトロスペクティブを実施し、ここまでの学習パスを通じて行って良かった点や改善点などを振り返りました。その内容をまとめます。
まず業務に関しては最初にdebug機能の実装を行った部分は、リリースに影響を与えない形で作業を行えたこと、またUIの実装を含めた一連のAndroid開発の流れを体験できた部分は良かったです。また、その中でZoomを活用したペアプロによって問題の解決や、ちょっとした疑問や問題の解決も行えてスムーズに開発を行うことができました。画面を共有して確認する中で、Android Studioのショートカット操作などにも触れ知見を広げることができたのも良かったです。他にも、モブプロやペアプロを行うことで、例外処理やbuild関連の部分など、学習パスから抜けていた部分などもサポートすることができました。
一方で、今回の開発上では直接触れなかったもののDatabase処理などについても、今後利用する場合に学習が必要になりそうです。また、モブプロはこの時期ちょうど導入し始めたばかりだった事もあり、まだメンバー同士慣れていない部分もあり、意見がうまくまとまらないなどの問題もありました。この部分は慣れるまである程度のファシリテートが必要だったように思います。現在は、モブプロのメンバーとしてドライバーもナビゲーターも行うようになりました。
現在はiOSに再び軸足を置いていますが、同時にAndroidのレビューなども行っていただくなど、両方のOSを開発できるエンジニアとして活躍していただいています。