DBRE Summit 2023 で「テーブル定義変更のレビューを効率化するための仕組み作り」を発表しました

先日8/24に開催されたDBRE Summit 2023 - connpassで「テーブル定義変更のレビューを効率化するための仕組み作り」というタイトルで登壇させていただきました。登壇は緊張しっぱなしスライドの文字を読むのが精一杯な状態だったので登壇スライドの補足を書いていきます。

登壇資料

イベントで使用したスライドはこちらになります。 speakerdeck.com

DBはMySQLでマイグレートツールにはRuby製のものを使っています。発表当日、今回の話ではDBやプログラミング言語に何を使っているかは重要ではないと考えていたので説明を省いていました。

これから先も人数比率を考えると「開発者 > DBRE」の構造は変わらないのでマンパワーで解決されることはないイメージです。開発者への教育やDBREがレビューしない構造にする手段もありますが、現環境では即座に取れる手段ではなかったので今回の仕組みを作ることにしました。

小さくリリースして成果を得たかった理由は、以下の２つ

リリースにより得る効率化による作業時間を早めに得て、その時間を早めに投資して効率化のサイクルを回したかったため
1つ目の解決に必要な要素が2つ目の解決に必要な要素に含まれており、必要要素の延長線にあったため
- 1つ目：PRへのコメントの表示
- 2つ目：PRへのコメントの表示 + 静的解析ルール

他業務の合間に作っていたので短期間で完了する目処がなかったことも理由の１つだったと思います。作業時間を得るための投資を複利で効果を得たかったようなイメージでした。

どこの職場でも開発用ドキュメントは作られていると思いますが、せっかく作ったドキュメントが見られていない職場も多いと思います。今回、必要なときのみ表示させる仕組みを作ったので、他の職場でも手間を掛けて作ったドキュメントの利用率を向上させる一助になればと思います。

PRテンプレートを使って常に表示させる方法もあるのですが、不要な時も含めて表示されていると慣れてしまい形骸化して見なくなる人が多くなると思い選択肢から外しました。

構文木を読み解く方法のほうが確実なのですが正規表現の場合、言語を問わずかつシンプルなルールであれば簡単にカスタムルールを作ることが出来て便利でした。

RuboCopは、Ruby製のマイグレートツールが大半であったこと、構文木を解析して少し複雑な条件のルールを作るのに楽が出来そうと思い試してみました。また個人的にRuboCopのCustomCop（カスタムルール）を作ったことがなかったので良い勉強になりました。

自動化したことによって、機械的な指摘や説明をする必要がなくなり時間が出来たおかげで、このタイミングではカラム追加ではなく、テーブル分割をしたほうが良いのではないか？などのドメイン設計に関するレビューに時間を割きやすくなったり、データベースのバージョンアップなどに時間を掛ける余裕が生まれました。

運営の方々、貴重な登壇の機会をありがとうございました！今回が初回開催でしたが他所のDBREの取り組みや考えていることを知る貴重な機会になったので是非二回目以降も続いていくことを期待しています。

また今回紹介した仕組みのサンプルコードはここに置いておきます。より良い仕組みや参考になれば幸いです。 github.com