こんにちは。LINEアプリの公式アカウント開発を担当している諏訪と楊です。この記事では、LINE Appの開発を進める上でAndroidの開発者のリソース問題を解決するため、iOSエンジニアがAndroid開発を学習し、実際に開発を始めるまでの過程や学習内容、実務内容などを紹介します。
안녕하세요. LINE 앱의 공식 계정 개발을 담당하고 있는 스와와 양입니다. 이 글에서는 LINE 앱 개발을 진행하는 과정에서 Android 개발자 리소스 문제를 해결하기 위해 iOS 엔지니어가 Android 개발을 학습하고 실제로 개발을 시작하기까지의 과정과 학습 내용, 실무 내용을 소개합니다.
開発を始めるにあたって 개발을 시작하며
上記はLINEクライアントチームのAndroidエンジニアとiOSエンジニアの当時の人口比率です。
위는 LINE 클라이언트 팀의 Android 엔지니어와 iOS 엔지니어의 당시 인구 비율입니다.
LINEクライアントチームではiOSエンジニアと比べるとAndroidエンジニアが少なく、LINEクライアント開発者全体の開発リソース比率の懸念がある一方で、LINEアプリはiOS/Android同時に同様のスペックで開発を行うことが求められており、機能リリースをスムーズに進行するためにも、このギャップの改善が組織としての目標でもありました。この状況は、我々のチームでも同様に影響があり、偏ったリソース配分になっていました。
LINE 클라이언트 팀에서는 iOS 엔지니어에 비해 Android 엔지니어가 적어, LINE 클라이언트 개발자 전체의 개발 리소스 비율에 대한 우려가 있었습니다. 한편, LINE 앱은 iOS/Android에서 동시에 동일한 스펙으로 개발하는 것이 요구되고 있어, 기능 릴리스를 원활하게 진행하기 위해서도 이 격차를 개선하는 것이 조직의 목표이기도 했습니다. 이 상황은 우리 팀에서도 마찬가지로 영향을 미쳐, 편중된 리소스 배분이 이루어지고 있었습니다.
そこでiOSエンジニアの楊さんにAndroidの開発にチャレンジしてみないかという相談をし、話し合いののち開発を行うための準備を進めました。またLINE Appの中の機能には、さまざまな背景によりiOSとAndroidで細かい部分での処理の違いなど、把握が難しい差異なども存在するため、両方のコードを理解し観察することで、それらの問題の発見や改善につなげることも目的としています。
그래서 iOS 엔지니어인 양 씨에게 Android 개발에 도전해보지 않겠냐고 상담을 했고, 논의 후 개발을 위한 준비를 진행했습니다. 또한 LINE App 내 기능 중에는 다양한 배경으로 인해 iOS와 Android에서 세부적인 처리 차이 등 파악하기 어려운 차이점도 존재하기 때문에, 양쪽 코드를 이해하고 관찰함으로써 이러한 문제를 발견하고 개선하는 데에도 목적이 있습니다.
学習内容 학습 내용
基本方針について 기본 방침에 대하여
ここでは実際にAndroid開発を始めるにあたり、学習に用いたリソースについて紹介を行います。
여기에서는 실제로 Android 개발을 시작하면서 학습에 사용한 리소스에 대해 소개합니다.
基本方針ですが、まずLINE Appでは歴史的な経緯などにより、必ずしもすべての箇所で最新のArchitectureに準拠しているわけではなく、例えば当時は多くの場所でAndroid View（XMLによるUI構築）が利用されていました。そのため、この時点ではJetpack Compose関連は重要度低いと考え学習を後回しにしました。
기본 방침은, 우선 LINE App에서는 역사적인 경위 등으로 인해 반드시 모든 부분에서 최신 아키텍처를 준수하고 있지는 않으며, 예를 들어 당시에는 많은 곳에서 Android View(XML에 의한 UI 구성)가 사용되고 있었습니다. 따라서 이 시점에서는 Jetpack Compose 관련은 중요도가 낮다고 판단하여 학습을 뒤로 미뤘습니다.
また、ドキュメントについては、基本的にはGoogleの公式的なドキュメントを利用し、英語での利用を推奨しました。これは日本語などの翻訳言語では最新の情報が適用されないケースがあったためです。一方LINE Appプロダクト開発に関連するドキュメントは幸い社内Wikiが整備されているため、社内環境の開発方法や社内ライブラリの利用方法などはそちらを参考するようにしました。
또한, 문서에 대해서는 기본적으로 구글의 공식 문서를 이용하며, 영어로 이용할 것을 권장했습니다. 이는 일본어 등 번역 언어에서는 최신 정보가 적용되지 않는 경우가 있었기 때문입니다. 한편 LINE App 제품 개발과 관련된 문서는 다행히 사내 위키가 정비되어 있어, 사내 환경의 개발 방법이나 사내 라이브러리 이용 방법 등은 그쪽을 참고하도록 했습니다.
その他、iOSエンジニアが効率的に学習できる方法を優先するようにし、スムーズに業務に入れるような形を目指しました。下記は実際に当時利用した学習リソースです。ただし、現在はGoogleの提供するチュートリアルの内容は変更されていて、Jetpack Composeによる構成がメインとなっています。
그 밖에 iOS 엔지니어가 효율적으로 학습할 수 있는 방법을 우선시하여, 원활하게 업무에 들어갈 수 있는 형태를 목표로 했습니다. 아래는 실제로 당시 이용한 학습 리소스입니다. 다만 현재는 구글에서 제공하는 튜토리얼 내용이 변경되어 Jetpack Compose에 의한 구성이 메인이 되고 있습니다.
Jetpack Composeについては、現在は標準として推奨されている構成なので、基本的にはそのまま公式コースに沿って進めると良いと思います。一方、もしこれからAndroid Viewに関する学習が必要になる場合は、CodeLab（Google Developers Codelab）でAndroid用のXMLレイアウトに関する内容を検索して参考にすることができます。またViewModel、Repository、Coroutine、Lifecycleなどのビジネスロジック関連も、上記と同様に現在は標準コースから外されたため、必要に応じてCodeLabから検索可能です。
Jetpack Compose에 대해서는 현재 표준으로 권장되는 구성이라 기본적으로는 공식 코스에 따라 진행하는 것이 좋다고 생각합니다. 한편, 만약 앞으로 Android View에 관한 학습이 필요해질 경우에는 CodeLab(Google Developers Codelab)에서 Android용 XML 레이아웃에 관한 내용을 검색하여 참고할 수 있습니다. 또한 ViewModel, Repository, Coroutine, Lifecycle 등의 비즈니스 로직 관련도 위와 마찬가지로 현재는 표준 코스에서 제외되어 필요에 따라 CodeLab에서 검색 가능합니다.
Android関連のドキュメント Android 관련 문서
Android App tutorial Android 앱 튜토리얼
https://developer.android.com/codelabs/basic-android-kotlin-compose-first-app?hl=ja#7
Googleの提供するアプリ開発のチュートリアルです。上述の通り、現在のドキュメントではJetpack Composeによるレイアウトを紹介されていますが、まずはサンプルアプリを動かしてみつつ、実際のアプリがどのような構成で、どのように動いているのかを理解していくことを目指しました。ここでは下記のことを学びました。
Google에서 제공하는 앱 개발 튜토리얼입니다. 앞서 언급한 대로, 현재 문서에서는 Jetpack Compose를 이용한 레이아웃을 소개하고 있지만, 우선 샘플 앱을 실행해 보면서 실제 앱이 어떤 구성으로, 어떻게 동작하는지 이해하는 것을 목표로 했습니다. 여기서는 아래 내용을 배웠습니다.
- Android Studioのインストール Android Studio 설치
- Android StudioのUI基本説明 Android Studio의 UI 기본 설명
- Android View(XML)によるレイアウト
Android View(XML)에 의한 레이아웃 - 色の変更やinterfaceの追加 색 변경 및 인터페이스 추가
- Fragmentの遷移 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を開発できるエンジニアとして活躍していただいています。
