個人的なデグレ対策を考える

2021年10月31日# 雑記

背景

先日、盛大にデグってる PR を作成してしまった。マージされた後、先輩に指摘されて気が付いた。

PR で満たしたかった要件は満たせていたが、他の機能に影響を及ぼすコードの書き方をしてしまった。結果、指摘してくれた先輩（影響を及ぼした部分の機能を作っていた）に巻き取って貰う形になった。

ここではその事象についてに個人的な振り返りや、対策に役立ちそうな参考資料などを書き連ねていく。

そもそも何でデグレは起きるのか？？

この記事に照らし合わせると「影響範囲の調査」、「セルフレビュー」辺りが現状で足りていなさそう。

影響範囲の調査は grep やタスク着手時に周りに確認を取る事で厳重な態勢は取れそうだが、セルフレビューってどうやるのが正解なのか？

まずは diff をちゃんと確認してからステージングする習慣を付ける！！

「それすらやっていないのかよ！！」って思う人もいるかもしれないが、慣れてくると脳死で全ファイルをステージングしたりもよくあるのが自分の現状なので、vscode の diff で 1 ファイル毎にいちいち確認してステージングしないとダメっだなーと痛感した。

で Pgithub で R を作り、レビュアー指定をしないで、自分がまずはセルフでレビューする。ここではコメントを入れていく！あとでコメント箇所をまとめて修正する。

問題なくなればレビュアー設定をしてレビューしてもらい OK！！

参考記事

品質を上げるためには自動化！が現代の基本で脳死でもデグレが起こらない状況を作る事が多くのエンジニアにとっての理想だと思うが、テストコードを書かない現場だと人力に頼らなきゃいけないのが現実である。

自分はテストコード記述の経験もなく、関わっているプロジェクトもテストコードがないのでせめて人力で注意深く品質を保つ最低限の動きは身につけたい。