LoginSignup
8
6

More than 5 years have passed since last update.

Androidアプリ開発をチームで行う前に決めておいたほうが良いこと

Last updated at Posted at 2018-12-11

はじめに

本記事は Android 初心者 Advent Calendar 2018 12 日目の記事です。

Android初心者ということで、開発をチームで行う前に決めておいたほうが良いことについて紹介します。

「開発を行う前に決めておいたほうが良いこと」としていますが、
正直決めておくと導入がスムーズかもね程度の内容です。

また、「開発を行う前に決めたから開発中は絶対に変えない」ではなく、
仕様や開発フロー、実装方法などの状況に合わせて、
柔軟に変えれる体制づくりが一番重要だと思うので、そういった点は注意しておいてください。
(ウォーターフォールかアジャイルかという話もあると思いますが…)

では、紹介していきます。

アーキテクチャ・設計パターン

まず、一番重要な事前に決めるべき点は、アーキテクチャ・設計パターンについてです。

なぜアーキテクチャが重要かというと、コードの保守性を高めるためです。

人気のあるアプリにするためには、リリースをしたら終わりではなく、
ユーザーからのフィードバックや分析結果などをアプリに反映して、
より良いものにしていくことが重要です。

人気のあるスマホアプリでも、1ヶ月に1度程度の頻度で継続的な改善のためのリリースを行っています。

このような頻度でアプリを開発、保守していくためには、コードの機能拡張性、保守性の高さが必要です。

アーキテクチャに則ったアプリ開発を行うことで、
適度な機能分割と、依存性の排除がされ、コードの保守性が高くなる場合があります。
(必ずしもアーキテクチャを採用するだけでコードの保守性が高まるわけではないです。
可読性の高いコードを書くことは常に意識しましょう。)

Androidアプリ開発のアーキテクチャ

Androidアプリでは、MVPやMVVMなど様々なパターンが用いられています。
それらの特性を比較し、どのアーキテクチャを使って開発をするかを決めて行きます。

アーキテクチャについては、開発を進めていくほど、
途中での変更が難しくなる(修正の影響範囲が大きくなる)ので、
開発チームのメンバーと十分に検討して使用するアーキテクチャを選びましょう。

Androidアプリのアーキテクチャについては、PEAKSさんから出版されている『Android アプリ設計パターン入門』が大変参考になるので、気になる方は買って読んでみてください。

AndroidOSのバージョンはどこまでサポートするのか

AndroidOSは現在、Android9(API28)までリリースされています。
そこで、最新版のサポートはするとしても、どこまで古いOSバージョンを対応するのかという問題が出てきます。

もちろん、古いものをサポートすればするほど、作業量や考慮しなければいけないことは多くなります。

世界版ですが、各OSバージョンのシェア率は以下のようになっています。
スクリーンショット 2018-12-11 20.17.09.png

日本版で考える場合は、新しいOSバージョンがもう少し多いと思います。
これらのデータをもとに、どこまでサポートするかを決めると良いでしょう。

幅広いOSをサポートすると、バージョンごとに処理を分ける必要がでてくる場合があります。
そのため、途中で対応バージョンを変更すると、そういった対応漏れが無いかを確認しなければいけないため、あらかじめ対応バージョンを確定させておくと楽でしょう。

使用する言語

Androidは、KotlinとJavaでの開発が公式でサポートされています。

今からAndroidアプリ開発を行うのであれば、
ほぼ間違いなくKotlinで開発を行ったほうが良いと思います。

ですが、Javaを使用している期間が長かったり、
Kotlinを知っている人がチームにいない場合は、
Javaの使用を検討したほうが良いと思います。

JavaなどのNullを許容する許容しないを宣言しない言語しか扱ったことのない人が、
いきなりそういった言語で開発を行うと、とりあえずNullを許容する変数で宣言してしまい、
せっかくのNull安全の仕組みが全く意味のない状態になってしまうことがあります。

なので、チームにKotlinを知っている人がいない場合は、
まずはチーム全体でKotlinについて勉強するか、Javaで開発を行うのが良いでしょう。

あまりオススメできないのは、KotlinとJavaが混在する状態で開発を進めることです。

JavaからKotlinに値を渡す際などに、
Kotlinでは、渡された値がプラットフォーム型と呼ばれる変数になってしまったり、
JavaでNullableアノテーションを追加するなど、
混在することが原因でやらなければいけないことが増えてしまうので、
どちらかの言語に統一することが望ましいです。

命名規則

基本的な命名規則は、特別な用語を用いる時以外は、英語で省略しないのが基本だと思います。

ですが、チーム内で特別な用語や英語に訳しにくい日本語を用いる場合は、あらかじめどのように訳すかを決めておかなければ、各々で訳してしまい、同じものを示しているのに、別々の用語になってしまう可能性があります。

あとから決めた命名に変更する場合は、それまでにどのような命名をされているかを把握して検索しなければいけないため、修正がかなり大変です。

そういった事態を避けるために、開発中にどのように訳すかわからなくなってしまった場合は、チーム内で相談して統一するようにしましょう。

まとめ

基本的に決めておいた方がいいことは、まだなにかある気がしますが、特に思いつかなかったので、これだけにしておきます。
新規アプリを開発する際に少しでもお役に立てば。

8
6
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
8
6