Yumemiのコードチェックをやってみた

Yumemi社のコーディングチェックをやってみようと思ってやり始めたら、思いの外興が乗ってしまった。

コーディングチェック最初は真面目に取り組もうとしていたのだけど、途中から方針ががらりと変わって自分の学習用の場になってしまった。

始めてから大体1週間位経ったので現在の経過を書いておこうと思う。

Kotlin2.0やK2コンパイラーもどんなもんなのか知りたいなあと思いながら、思うだけで終わっていたので、取り組むのに丁度良い機会だなと思った。

アプリの機能としてはシンプルにGithubのリポジトリを検索するだけの機能があるアプリである。依存しているライブラリが少なく、試すにはちょうどいいサイズ感だったのも幸いした。

Kotlin2.0になったからといって、そんなに大きく変わったという印象はない。自分のプロジェクトに適用するのは心理的なハードルが高いのだけど、コーディングチェックは挑戦するのにちょうどよかった。

新たな機能としてExplicitBackingFieldsというものがある。

正確には2.0では実験的に使える状態なだけだが、Android開発でよくあるこれを解決できるいい機能だと思う。

1
2
3
4
5
6
7

// ViewModelでよくみるやつ
private val _isLoading: MutableStateFlow<Boolean> = MutableStateFlow(false)
val isLoading: StateFlow<Boolean> = _isLoading.asStateFlow()

// ExplicitBackingFieldsだとこう書ける
val isLoading: StateFlow<Boolean>
    field = kotlinx.coroutines.flow.MutableStateFlow(false)

ViewModelで状態を変化させるのに_isLoading.value = trueとしないといけない気持ち悪さがあったものが、シンプルに書けていいなと思う。

ちなみに今は実験的に使えるというだけで、プロダクションコードには入れるのは憚れる。

Android Studioでビルドできるけど、赤の波線が常に入って非常に気持ち悪いことになってしまうし、fieldの定義に完全修飾名を書かないと動かない別に完全修飾名は必要なかった。

使うにはbuild.gradle(.kts)で明示的に設定を有効にしなければならない。

1
2
3
4
5

kotlin {
    sourceSets.all {
        languageSettings.enableLanguageFeature("ExplicitBackingFields")
    }
}

このStackoverflowを参考に導入した、というかそのままだけども。

ここよると2.2で入るらしい。待ち遠しいなあ。

Multiplatformにも挑戦したいなあと思っている。これも挑戦するにはちょうどいいサイズ感だなと思って現在取り組んでいる。

KMPはどう始めたらよいのかよくわからないので、ハードルが高かった。というか高いと思っている。新規で作るのは簡単でも、既存プロジェクトに導入するのは難しい。

既存のプロジェクトにKMPのモジュールを追加するにはAndroid Studioを使うしかないのだろうか。Shared Moduleとしての追加しかなかったから、ここから育てるしかないという感じだろうか。

IntelliJ IDEAからのモジュール追加の方法はなんかさらによくわからなかったので諦めた。

そもそもKMPの導入はまだ絶賛作業中なので、ちょびちょび試していきたいと思っている。

CIの構築には興味があってやってみたいなあとは思っていたが、なかなか導入する機会に恵まれず。

自分のアプリはクローズドな環境で開発しているし、既存のプロジェクトはすでに構築済みだったりして、自分で1から導入するいい機会になった。

ちょっとGithub Actionsとお近づきになれたかなあと思う。

テストコードは完全に自己流。今回のコードチェックではあまり意味のあるテストコードが書けていない。

私の場合はコードを実装するのにテストコードで動作確認しながらやり、その結果としてテストコードが残るという感じになっている。

これはTDDとは違うよなあと思いながら、今後の課題としたい。

最後にこういったコーディングチェック課題を提供してくれる方々に感謝を述べたい。

最初は応募するつもりで始めたのだけど、途中から自分の学習のためと割り切って進めることになった。

やってみて思ったのは、私はコミットの粒度が大きくなる傾向があるなあということ。チーム開発の経験が少ないため、こういう機会でもないと再認識できなかった。

個人開発でも1度に変更が大きくなりすぎて、やっぱもとに戻したいけど変更箇所が多すぎてどこをどう戻せばいいかわからなくなって放置しているところが多い。こういうところも一度に多くのコードを触ってしまうクセとして出ているのだろう。今後の反省として活かしたい。

特にCIの構築は、いきなり完成形を目指してわけがわからなくなってしまった。とりあえず簡単なとりあえず動けばいいというレベルで実装して、少しずつ改良するようにしたい。

これはコードを変更することを嫌うことから来ているんじゃないかなあと思う。だからいきなり完成形を目指してやってしまうのだ。

そういう自分の悪い癖が再認識できてよい機会となった。

https://github.com/gen0083/android-engineer-codechechek