はじめに

この記事はAndroid Advent Calendar 2023 12日目の記事です。
ちなみに、本日12月12日は【良い字一字】の語呂合わせにちなんで今年の漢字が発表される日だそうです。いよいよ今年が終わるのだという実感が湧いてきますね。

さて、皆様にとって今年1年はどんな年でしたでしょうか？
非常に忙しかった、新技術にチャレンジしてドキドキワクワクだった、とにかくバグを潰していたら1年が終わろうとしていた等色々あるかと思います。

自分としては、今年一年は新規プロジェクトに携わることが多い1年でした。
なのでこの記事で新規開発を行う上でやったこと・失敗したことをまとめていこうかと思います。

あくまでほんの一例ですが、これから新規プロジェクトを行う方の一助になれば幸いです。

プロジェクト初期にやったこと

使用技術の選定
モジュール作成
build.gradleの整備
AndroidManifestの整備
証明書作成
サンプルクラスの作成

簡単に一つずつ見ていきます。

使用技術の選定

まずNew Projectする前に、使用技術・ライブラリの選定を行いました。
特に最近だと既存のAndroid Viewを使うのか、Jetpack Composeを使うのかという判断もこの段階で行うことになるかと思います。
また、この段階でコーディング規約の検討も行いました。（命名規則、禁止事項など）

モジュール作成

責務を明確に分けるため、初期段階でモジュールを作成しました。
ツールバーの「File」 > 「New」 > 「New module...」から作成することができます。
（参考：ライブラリモジュールの作成）

build.graleの整備

プロジェクトの基盤となるbuild.gradleの整備を行いました。
具体的には下記の作業が必要になるかと思います。

ビルドバリアントの設定
- debug/releaseでそれぞれの設定
- 検証環境・本番環境の設定
アプリバージョンロジックの整備
ライブラリやpluginの導入

AndroidManifestの整備

上記のgradle設定で環境を分けたので、AndroidManifestも環境ごとに作成しました。
src/配下にgradleのproductFlavorsで設定したキーと同じ名称のディレクトリを作成し、その中にAndroidManifestを作成すると環境を変えたときに環境名と同じディレクトリにあるソースを参照してくれるようになります。（参考：ソースセットでビルドする）

また、忘れがちなパーミッション設定などもやっておきましょう。

証明書作成

.aab/.apkファイルを作成するために必要なキーストアもこの段階で作成しました。
ツールバーの「Build」 > 「Generate Signed Bundle/APK...」> AABかAPKを選択して「Next」 > 「Key store path」の「Create new...」から作成できます。
（参考：アップロード鍵とキーストアを生成する）

サンプルクラスの作成

他のメンバーとの認識を合わせるためにも、本実装に入る前にサンプルのクラスを作っておくことをおすすめします。
そうすることでどのクラスをどこに配置するかが明確になりますし、設計が不十分であった場合はこの段階で気づくことができます。

失敗したこと

早期にlintを導入しなかった

実装を開始して少ししてからlintを入れたことがあったのですが、ある程度実装を進めてから導入すると自動で修正できないエラーがちらほら出てきました。（ktlintFormatのワイルドカードimportなど）
こうしたエラーは手動で解決するしかないため、lintを導入するのが遅くなるほど無駄な手作業の時間が増えてしまいます。
lintを入れるなら早いに越したことはないという学びでした。

READMEの作成を後回しにした

新規実装時は何かとやることが多いので、正直READMEのようなドキュメンテーションの整備に時間をかけることが難しい場面も多々ありました。
またそうして忙しい日々が続いていくと何をREADMEに書けばいいのかという軸がどんどんぶれてきてしまい、筆を取る手が重くなってしまいます。
その結果、新しくプロジェクトにメンバーが入るという時にてんやわんやしてしまい、既存メンバーも新規メンバーもお互い大変な思いをする結果となってしまいました。
少し面倒だとしてもREADMEは初期構築序盤の段階でババッと書いた方がいいなという反省でした。

最低限これらだけでも書いておきたいですね。

プロジェクト概要
クラス構成
環境構築手順
PRを出す前に確認すること

検証環境でapplicationIdを設定しなかった

build.gradleでapplicationIdSuffixを設定することで、デフォルトのアプリケーションIDの末尾に追加文字列を付与できます。
こうすることで、「検証環境はデフォルトアプリケーションID.dev」とするなどの対応が簡単にできます。
（参考：ビルドバリアント向けにアプリケーション ID を変更する）

これを設定しないと、どの環境でも全て同じアプリとみなされてしまうため、検証アプリをインストールした後に本番アプリを検証したい場合は一度検証アプリをアンインストールしなければならないなど非常にめんどくさくなります。
また、外部SDKを利用する場合などは環境ごとのApplicationIDを求められることがあります。
自分の場合は開発中盤でこのApplicationIdSuffixを設定していないことに気づき、外部SDKの設定など全てやり直しになってしまいました...

終わりに

久々に記事を書いたのでなんだか緊張しましたが、今年中にこのテーマで何かアウトプットがしたかったのでアドカレに参加してよかったです！

プロジェクト初期に何を設定するかはプロジェクトによって千差万別かと思います。
こちらで紹介したのはあくまでほんの一例なので、もし「こういうのもやった方がいいよ」といった情報があればぜひ教えていただけると嬉しいです！