はじめに

この記事は Hamee Advent Calendar 2020 23日目の記事です。
この記事を書くにあたって、2019年のアドカレを振り返ってみたところ、一人でこっそり使ってた仕組みを、他の人にも使ってもらえるようにした話。を書いていたみたいです。何かを作ったよ！ここを工夫したよ！って記事ですね。気が向いたら読んでやってくださいNE！

さて、本題に入ります。
新卒1年目の時は、開発をして検証を依頼するだけのことが多かったのですが、2年目になって後輩ができたのもあって、徐々に検証依頼されることも多くなりました。ここでの検証というのは、開発者がある機能を追加するなり改修するなりしたときに、解決したい課題をその方法で本当に解決できるのか、その方法が最善な選択なのかどうか、既存の機能に影響を与えていないかどうかを確認することです。

そう頭ではわかっているのですが、結果としてリリース可否の段階でリリース判定者に差し戻しされてしまうことが結構あり、その度、開発者とリリース判定者に申し訳ない気持ちになっています。
もちろん、検証者としては、頼まれたからにはリリースしても問題のない品質であることを速く正確に確認してあげたいし、もし開発者が気づいていないバグや考慮漏れなどがあればそれを指摘し、リリース判定者を安心させたいものです。

そこで、指摘を受けるたびに、自分の未熟さを再認識し同じ指摘を再びされないように、とslackのtimesに記録してきました。ただ書き留めるだけでは忘れてしまうのと、開発者として検証項目を考慮するときにも役立つので、この機会に振り返ってみようと思います。
コードレビューの話よりももっと手前の話なので、もしかすると誰かの役に立つかもしれないし、全く役に立たないかもしれませんが......

改修する機能やそれを呼び出している機能でわからないことは無いようにする！

タイトルそのままですね。改修対象の機能が、どこでどのように呼び出されるのか、どの画面で使われているのかを全て調べるということです。同じメソッドでもその呼び出し元の環境によって挙動が異なるかもしれません。理解が曖昧な部分に実は重要なロジックが書かれていたということもあったりします。
ソースコードだけを追っているとわかりにくかったり、見逃してしまうこともあるかもしれませんので、必ずマニュアルや資料があればそれらも確認し、実際にユーザーと同じように動かして確認することを意識しようと思います。

コメント文を過信しすぎないこと

これもそのままなのですが、ちゃんとコードを読めよという話です。改修に改修を重ねたプロダクトだと当初のコメントと実際のコードの内容に解離が発生することがあります。実際にあったのは、元々はとあるユーザーさんの要望に答えるために実装されたメソッドだったものが、現在では全ユーザーが共通で利用する可能性のあるメソッドになっていたということがありました。改修時にコメントの修正をし忘れている場合もあるので、コメントは過信しすぎずにコードを読んで実際の処理を把握した方がいいと思います。

すでに入っている値やデータの対応についても考えること

バグなどによって、本来入ることが想定されないデータがDBのカラムに入ってしまうことがあるかもしれません。このような時は、バグの原因を突き詰めてバリデーションを強化するなどの対応をすることになると思います。この対応により、新しく入ってきた値には問題はなくなるのですが、改修以前に入っていたデータに関しては直接DBにクエリを流すなどして対応しない限り変わりません。そのままだと、既存のデータを呼び出して使うときに、想定外の文字列などが混入した状態で呼び出されてしまい、動作に影響を与え続けるかもしれません。
そのため、改修だけでなく、既存のデータにも気を配っているかを確認するように心がけようと思います。

ユーザーに画面から設定などを変更してもらったときに、DBで変更内容を確認すること

私の業務では、稀に特定のユーザーのDBに直接変更を加えることがあります。そのとき、画面からできることはできるだけユーザーにやっていただくようにして、データの不整合がなるべく起きないようにします。ただし、ユーザーが変更を加えられるのは、現在表示されているものだけです。ですが、過去のバージョンの設定値や項目を、データの整合性を担保したり、将来的に設定を再利用するなどの理由で物理削除ではなく論理削除(非表示)で残しておくこともあると思います。
このような非表示のデータは、ユーザーが変更することができないため、こちら側で適切に処理をしてあげる必要があります。今は非表示の設定も表示されるときが来ないとも限りませんので、その時にユーザーが困ることがないように気を付けようと思います。

改修前後で予期しない変更がないか、DBのカラムを比較して確認してみる

影響範囲の大きな改修やリファクタでは何が起きるかわからないということもあるかもしれません。そのような時は変更前後のDBの状態をdumpなどで保持し、変更前後のカラムを比較します。このとき、本来変更されるはずのないカラムで差分が出ていたら、なんらかのバグが残っている可能性があります。変更されるはずのカラムが変更されていない場合もこの方法で気づくことができます。
こんな簡単な例ではありがたみがあまりないかもしれませんが、ageが20から200に変わるなんてことがあればさすがにバグに気づけそうですよね。
必要であれば検証者として、このチェックをやってみるといいかもしれません。

変更前

id	name	age
1	test	20

変更後

id	name	age
1	test	200

おわりに

このほかに、画面にちゃんと出ているからと言って、DBのカラムを見ないのは危険だぞ、とか、変更箇所にあるif文は全部通ることを確認して、とかまぁ当たり前と言われてしまいそうなメモが残ってました......（おいおい......）
とはいえ、先輩方から指摘いただいたことではあるので、真摯に受け止めて日々の検証や開発に生かして行こうと思います。