先日、盛大にデグってるPRを作成してしまった。
原因分析した結果、「セルフレビュー」と「変更箇所の影響範囲の調査」が足りていない事が分かった。
背景
先日、盛大にデグってる PR を作成してしまった。
マージされた後、先輩に指摘されて気が付いた。
PR で満たしたかった要件は満たせていたが、他の機能に影響を及ぼすコードの書き方をしてしまった。
結果、指摘してくれた先輩（影響を及ぼした部分の機能を作っていた）に巻き取って貰う形になった。
ここではその事象についてに個人的な振り返りや、対策に役立ちそうな参考資料などを書き連ねていく。
原因を調査
そもそも何でデグレは起きるのか？？
https://qiita.com/Marusoccer/items/f3aed48c68d16fe8da1d
この記事に照らし合わせると「影響範囲の調査」、「セルフレビュー」辺りが現状で足りていなさそう。
セルフレビューってどうやるの？？
影響範囲の調査は grep やタスク着手時に周りに確認を取る事で厳重な態勢は取れそうだが、セルフレビューってどうやるのが正解なのか？
まずは diff をちゃんと確認してからステージングする習慣を付ける！！
「それすらやっていないのかよ！！」って思う人もいるかもしれないが、慣れてくると脳死で全ファイルをステージングしたりもよくあるのが自分の現状なので、vscode の diff で 1 ファイル毎にいちいち確認してステージングしないとダメっだなーと痛感した。
で Pgithub で R を作り、レビュアー指定をしないで、自分がまずはセルフでレビューする。ここではコメントを入れていく！あとでコメント箇所をまとめて修正する。
問題なくなればレビュアー設定をしてレビューしてもらい OK！！
参考記事
https://zenn.dev/sirosuzume/articles/64763fad0efff7
まとめ
品質を上げるためには自動化！が現代の基本で脳死でもデグレが起こらない状況を作る事が多くのエンジニアにとっての理想だと思うが、テストコードを書かない現場だと人力に頼らなきゃいけないのが現実である。
自分はテストコード記述の経験もなく、関わっているプロジェクトもテストコードがないのでせめて人力で注意深く品質を保つ最低限の動きは身につけたい。
また、「PRで要件を満たしているか」はレビュアーが確認していくれるが、「他の機能に影響がないか？」、「そのコードが表現として正しいか？」
この辺りを厳格にチェックするかはレビュアーによる所が大きい。今回の一件からレビュイー側でこの辺りは厳格にチェックする必要があると感じた。