フィードバック part2

[Kotaro666-dev]

• [x] Singletonのアノテーションがシングルトンである必要性が感じられないところにもついていました。自動生成されたコードをみるとわかりますが、シングルトンにすると synchronized { } によるロックが発生しますしコードサイズが大きくなります。必要なところだけにつけることをおすすめします。
• [ ] SearchResultsDetailUseCase を見ると例外をキャッチしてそのままスローしてる処理がありました。例外のキャッチする箇所は少ない方が可読性がよくなります。（ハンドリングしたい場合や変換したい場合など意図がある場合を除きます。）
• [x] binding 変数を Fragment が保持しており、 onDestoryView 後もメモリにViewが残ってしまうため解放したほうがよいです。（画像を多用するアプリ等では Out of Memory の原因になります。）
• [ ] ユニットテストを実行すると実際にGitHubと通信してしまうように見えます。テストコード中では外部との通信を避けましょう。（テストだと思って気軽に実行すると思わぬ副作用があるリスクがありますし、CI/CDなど任意の環境で実行できるようにするためです。）

[Kotaro666-dev]

binding 変数を Fragment が保持しており、 onDestoryView 後もメモリにViewが残ってしまうため解放したほうがよいです。（画像を多用するアプリ等では Out of Memory の原因になります。）

以下のコミットで対応済みです。

https://github.com/Kotaro666-dev/android-project-refactoring/commit/de995ade6dde4276d29df92224f7f7e05b2f2ec0

[Kotaro666-dev]

SearchResultsDetailUseCase を見ると例外をキャッチしてそのままスローしてる処理がありました。例外のキャッチする箇所は少ない方が可読性がよくなります。

果たして、これは可読性がよくなるのだろうか。

void main() {
    try {
        doFirstJob();
    } catch (e) {
        // Handle exception
    }
} 

void doFirstJob() {
    doSecondJob();
}

void doSecondJob() {
      throwExeption()
}

void throwException() {
     throw Exception();
}