クオカード デジタルイノベーションラボの齋藤です。 2020年6月にQUOカードPay オンラインストアの内製化を行いましたが、そのタイミングでは修正しきれなかった問題が残っていました。 今後の機能追加や改修を行う上での障害になる為、方針を決めた上でリライトを進める事にしました。
方針
修正することが多いWebのバックエンドから着手する。
できるだけ部分的に修正する
Pull Requestが巨大になってしまうとコードレビューが難しくなる為、またリリース時にトラブルが発生するリスクも大きくなるため、できるだけ局所的な改修になるように進めています。
- 細かい部分に拘りすぎないようにし、まずは全体的に改善する
一旦全体的に厳しい部分を修正したい為、まずは修正内容で記載した内容のみを修正し、それ以外の問題については後回しにすることにしました。
今回導入するライブラリ
以下のライブラリを今回新たに導入しました。
- JUnit 5
通常は kotest + MockK という組み合わせになると思いますが、Kotest のクラス群でコンストラクターにわたす関数ないしは、 init で書く処理は、関数の見た目とは反してクラスボディにかなり近い性質を持つという特性があります。 そのため、テストを書いているときに値を関数の見た目に騙されて変数等の状態と誤解してテストを書いてしまうケースがあり、今回のようにベンダーから引き継いだ状態のよくわからないコードをリファクタリングしていく際にテストが悪いのかプロダクションコードが悪いのか混乱する可能性が考えられたので、書いている状態を勘違いしづらい JUnit を使った方がよいと判断しました。
- MockK
Kotlin で作ったクラスでもモックできるというのが特性(Mockito だとプロダクションコードを open にしないといけない)なので採用することが多いですが、 Kotlin で使うようにする目的で作られているので Kotlin の用語にあわせた API になっているというのもポイントであると考えています。 ( Mockitoの場合、動作を記録するのに、 Kotlin の予約後である when という API の使用が絶対で、その場合に
`when`
と書かないといけないため、 Kotlin では使いづらいというのがあります ) ただし、 spring-test の MockBean ではMockitoが使われているので、そのままMockito を使っています。
- spring-test
優先する修正内容
nullをOptionalで書き換える
フィールドインジェクションをコンストラクタインジェクションに変更する
デッドコードを消す
できるだけテストを書く
全てテストを書こうとすると非常に時間がかかってしまう可能性がある為、今回は難しい手動でテストする形も許容する事にしました。
- 依存を減らす
テスト作成を容易にするため、クラスを分割するなどし依存しているモジュールの数を減らそうとしています。
2巡目以降のリファクタリングで対応する予定のもの
今回はサーバーサイドを優先に進める事にしましたが、以下についても今後対応していこうと思います。
フロントエンド
バッチ
Kotlin化
できるだけ参照透過に書き換える
