この記事はPhotoruction Advent Calendar2021の16日目です。
まずはこちらの記事をお読みください。
また、この記事はあえてネガティブなことを抜き出して書いています。記事を読むタイミングによっては改善済みの場合もあります。
TL;DR
理想を決めたけど、あれもこれもまだまだダメダメです。
ただし、よくなる兆しも、よくしていく動きもあります！
これからのPhotoruction Androidアプリにご期待ください！
第1段目のゴール目標と現在
第1段目のゴールは「秩序をしっかり作って、秩序に慣れてもらうこと」です。
それで、今どうなの？というと、
- 設計方針については理解できてるし、新しいものはそれに沿って作れているしリファクタする時も沿えている
- ただ、これまでに作られた膨大なコードについては全然まだまだこれから
というところです。
これからどれだけ全然まだまだなのかをいくつか数字を出しながら説明していきます。
ファイル数からわかること
| 種類 | 数 | 条件 |
|---|---|---|
| Activity | 63 | ファイル名にActivityがついている |
| Fragment | 73 | ファイル名にFragmentがついている |
| ViewModel | 59 | ファイル名にViewModelがついている |
| 41 | ↑のうち、ViewModelもしくはAndroidViewModelを継承しているクラスのあるファイル | |
| Repository | 27 | ファイル名にRepositoryがついている |
| Realm | 49 | RealmObjectを継承しているクラスのあるファイル |
| Room | 26 | ＠Entityが付いているクラスのあるファイル |
これだけでもわかることがいくつかあると思います。
- Realm / Roomのファイルに対してRepositoryのファイルが少ない → Repositoryを経由していないDBアクセスが大量にある
- Activityの数が多い → ViewがActivityに直接紐づいているものが多い
- ViewModelって名前なのにAACのViewModelを継承してないファイルが多くある(これはそういう方針なのであれば問題ないと思うが、そうではないので問題と認識している)
- ViewModelがActivity / Fragmentに比べて少ない→Fat Activity / Fat Fragmentになっている
ステップ数からわかること
| 種類 | 数 | 条件 |
|---|---|---|
| 平均 | 210.8 | 拡張子が.javaのファイルの行数の平均 |
| 75.8 | 拡張子が.ktのファイルの行数の平均 | |
| 中央値 | 92 | 拡張子が.javaのファイルの行数の中央値 |
| 35 | 拡張子が.ktのファイルの行数の中央値 | |
| ファイル | 19 | 拡張子が.javaのファイルの1000行を超えているファイル数 |
| 0 | 拡張子が.ktのファイルの1000行を超えているファイル数 |
- 特にJavaのファイルに関して、ステップ数が多い → 適切な責務分けがされていない
- Kotlinのファイルは比較的新しいこともあり問題があるようには見えない → 当然見えづらくなってるだけで問題点のあるコード、ファイルはある
- 平均と中央値の差が大きいことから、とにかくステップ数が多いファイルがいくつかありそう
こちらはこういったところでしょうか
コードからわかること
まだまだアーキテクチャに沿えていないコードが多いです。
それは↑のところからわかることも多いですが、実際はそれ以上に、アーキテクチャに沿えていない ≒ Fat Activity / Fat Fragmentなので、責務の分割から始めることになったり、そもそも密結合すぎて大幅に書き換えないとアーキテクチャに沿えなかったりというファイルも多くあります。
また、コードとはまた違いますが、package構成もぐちゃぐちゃだったりします。
これもアーキテクチャを決めたタイミングでpackage構成を決めているので、とりあえずはAndroid Studioの機能を使いながら移動させるだけですが、1072ファイルあるのでそれだけでも大変です💦
そのほか、あげればキリがないほど課題はありますが、本当にキリがなくなるのでこの辺で
1年で良くなったこと
辛そうな話ばっかりだとアレなので、最後によくなってることを話して終わりにしたいと思います。
2021年(2020年からやってることもあるんですが)で改善したことも併せて記載しておきます。
アーキテクチャの導入
これまでは設計の「せ」の字もないコードだったのをアーキテクチャを決め、設計方針を固めて書くようになったので、責務の分かれたいわゆるいいコードに近づいたと思います。
CI/CD/GitHub Actionsの導入
CIやActionsはまだまだできることはあるのですが、Lintの指摘やビルドが問題ないかなどまだまだ基本的なことしかやれていませんが0→1の大きな変化だと思っています！
やれることはあるのでこれからもどんどん面倒なことを自動化させたいなと思います。
今はライブラリのアップデートがめちゃくちゃ面倒なのでCIで自動でPR作られるようにしたいなって思ってます。
テストの導入
テストに関しても、これまで全く書かれていませんでした。そもそも書けるようなコードになっていません。(これは現在進行形です)
なので、アーキテクチャを決めて、それによって責務分けをしたタイミングで、次はテストコードを書くぞと決めて、新しいところのViewModelなど書くべきところは書くようにし出しました。
こっちもまだまだこれからですが、TDD的な書き方をしたり、テスタブルなコードを書けるようにして、どんどんよくしていきます！
今後どうしていくのか
とにかく、今は少しでも多くのファイルをアーキテクチャに沿った構成に近づけることを最も優先しています。(開発の傍らですが)
まだしばらくそちらに時間がかかると思いますが、大方の対応が完了すると別のつらみが出てくると思っています。そうなった時にはまた新しい施作を実行して行きます。
来年のアドベントカレンダーでは別の課題の解決をしてるといいな
株式会社フォトラクションでは一緒に働く仲間を募集しています
