「データベース・リファクタリング」を読んだ

「データベース・リファクタリング データベースの体質改善テクニック」を読みました。

データベース・リファクタリング

内容はタイトルの通りで、前半は発展型データベース開発の概念と手法の基本、後半は各リファクタリングのリファレンスです。

データベースの質を高めるために、一通り「こんなことができるんだ」と知っておくと良いと思える内容でした。

データベースの修正は「面倒」で「怖い」と言った理由で避けられがちですが、 この本を読むと、それに立ち向かうための武器や考え方が得られるんじゃないかと思います。

以下、個人的に印象に残った点について書いてきます。

移行期間を設ける

当然といえば当然なんですが、Web API やライブラリの場合と同じで、 移行期間を設けることで、保守コストはあがりますが、移行がしやすくなります。

移行期間中は新旧両方のコードが動くので、大規模デプロイを避け、少しずつ対応を進めることができます。

小さい変更を少しずつ反映していくほうが安全で確実ですね。

確実に動く小さな変更を早めにマスターに反映していくことができれば、 他の人の作業とぶつかる可能性も下げることができます。

リファクタリングの意義

コードは情け容赦なくリファクタリングしなければならない。 というのも、質の高いソースコードを扱っているときが、一番生産性があがるからだ。 コードに新しい機能を追加するときには、まず「このコードはこの機能を追加するためにもっとも良い設計になっているだろうか」と考えなければならない。

同意しかないので特に追記することはありませんが、「作業前に周りをキレイにする」という作法はもっと広まってほしいなと思います。

データベースの不吉な臭い

本に記載されていた「臭い」は以下の通りです。

• 複数の目的に使われるカラム
• 複数の目的に使われるテーブル
• 冗長なデータ
• カラムの多すぎるテーブル
• 行の多すぎるテーブル
• 「スマート」カラム
• 変更の恐怖

噛み砕くと One Fact in One Place が守られており、かつ理解しやすい設計になっているかが鍵だと思います。

コードの場合は単一責任原則が守られており、かつ理解しやすい設計になっているかが鍵だと考えているので、 コードでもデータベースでも、「不吉な臭い」の根幹は似ているなと感じました。

この辺の嗅覚を上げるには SQL アンチパターン が非常に有効だと思います。

necojackarc.hatenablog.com

設計とドキュメントの関係

設計がきれいなほど、必要なドキュメントは少なくなる

なるほど確かに、と思いました。

ドキュメントやコメントが不要だとは考えていませんが、コメントやドキュメントで説明が多く必要なときは、 そもそも設計自体が不適切な場合は多いと感じます。

データベース・アクセスのカプセル化

カプセル化されていれば、当然変更箇所が少なくなるので、データベースの変更コストが少なくなります。

これはいわゆる、結合度を下げる（凝集度をあげる）とメンテナンスコストが下がるのと同じです。

例えば Rails の場合、where を外から呼ばず scopeを使い、 ActiveRecord 外にデータベースの詳細を染み出させないようにする、などが一例として思いつきました。

データベース・リファクタリングと政治

組織にデータベース・リファクタリングを取り入れたければ「政治ゲームに参加する」必要もある

変革を起こすには、どうしても政治力が必要になりますよね。そりゃそうだ。

まとめ

コード・リファクタリングよりも、どうしてもコストはかかりますが、 データベース・リファクタリングも十分日常的に行える作業だと思います。

大事なのは、コード・リファクタリングと同じく、

• 「不吉な臭い」を嗅ぎ取ること
  • 単一責任原則 / One Fact in One Place などの基本原則を抑える
• 小さな変更を繰り返し適用すること
  • 安全性も確実性も高まり、更に環境を最新に保ちやすい

あたりだと思います。

唯一不変なものである変化に対応するには、継続的改善が必須です。

データベースも継続的改善を行っていきましょう！