23.1 目的: ベストプラクティスを採用する
ソフトウェアエンジニアリングのベストプラクティス
- ソースコードのバージョン管理
- ユニットテストや機能テストの自動化・実行
- ドキュメント、仕様書、コードコメントを書く
ベストプラクティスを怠るとプロジェクトは失敗に向けて進みだす
23.2 アンチパターン: SQLを特別扱いする
アプリケーション開発のルールはデータベース開発には当てはまらない
=> 「ディプロマティック・イミュニティ(外交特権)」
そう考えられる理由は
- データベース管理者はいくつかの開発チームを掛け持ちすることがあり、「お客さん」のように扱われる
- SQL言語がアプリケーションコード内で特殊な言語として扱われる
- アプリケーションコードを記述するときに使える高度なIDEツールがデータベース開発向けにはない
- データベースに関する知識や運用権限が1人のデータベース管理者に集中してしまう傾向にある
23.3 アンチパターンの見つけ方
以下のような兆候がある
- 軽量なエンジニアリングプロセスの採用
- データベース管理者をバージョン管理システムのトレーニングに呼ばない
- データベースのテーブルや列が使われているかの調べかたがわからない
- データベーススキーマ変更の適用プロセスに従っていない
23.4 アンチパターンを用いてもよい場合
すべてのコードにドキュメントやテストを書くのは大変ですよね？
何度も使うコードに対してはベストプラクティスを適用しましょう
その場限りのコードであれば、そうしなくてもいいでしょう
一時的なものかの判断は使い終わった後すぐに削除できるかどうか
削除できないのであれば、バージョン管理システムに保存し、ドキュメント等を書きましょう
23.5 解決策: 包括的に品質問題に取り組む
ソフトウェア開発者の多くが行っているテストは品質管理であり、大きなストーリーの一部でしかなく、ソフトウェアエンジニアリングのライフサイクルは品質保証を伴う
品質保証は3つの部分からなる
- プロジェクト要件の明確な定義・文書化
- 要件に対する解決策の設計・構築
- 解決策が要件を満たしていることの確認・テスト
データベース開発における品質保証
- 文書化
- バージョン管理
- テスティング
23.5.1 文書化
データベースの要件と実装はアプリケーションコードと同じように文書化すべき
以下のチェックリストを使って文書化しましょう
- ER図
- テーブルとその関連を表す図
- 列・キー・インデックスなどを記すための表記法がある
- 図表作成用の製品のなかにはER図の表記法要素を含むものもある
- テーブル・列・ビュー
- データベースを説明する文書も必要
- 説明する対象
- 参照テーブル・交差テーブル・従属テーブル
- 列の名前やデータ型
- ビューの目的や想定されるテーブル間の関連
- 関連(リレーションシップ)
- スキーマ上の制約の根拠となるビジネスルール等の説明
- トリガー
- トリガーに実装しているビジネスルール
- ストアドプロシージャ
- どのような問題を解決するものか
- データに対する変更を行うか
- 入出力パラメータのデータ型と意味
- SQLセキュリティ
- データベースユーザの定義
- 各ユーザのアクセス権
- システムレベルのセキュリティ対策 等
- データベースインフラストラクチャ
- データベースの種類とバージョン
- データベースサーバーのホスト名 等
- オブジェクトリレーショナルマッピング
- アプリケーションコードに実装されるビジネスルール
- データの妥当性確認・データ変換
23.5.2 バージョン管理
データベースサーバーが故障によって完全にダメになってしまった場合どうしますか？
変更を取りやめたい場合、どのように元に戻せばいいでしょう？
アプリケーションコードと同様にデータベースを扱うコードに対してもバージョン管理を用いましょう
バージョン管理下に入れておく、ファイル
- データ定義スクリプト
- トリガーとプロシージャ
- ブートストラップデータ
- ER図とドキュメント
- データベース管理スクリプト
23.5.3 テスティング
品質保証の最終パートは、品質管理です
テスティングの重要な原則の1つは独立(isolation)です
テストごとにシステムの１部分のみを検証することで、欠陥が存在する場合に、可能な限り正確に、欠陥の箇所を絞り込める
アイソレーションテストはデータベースにも適用できます
データベースの妥当性を検証するテストのためのチェックリストを以下にしめす
- テーブル・列・ビュー
- 存在することのテストだけでなく、削除したテーブルがないことを確認する否定テストも行いましょう
- 制約
- 制約に違反するようなステートメントを実行し、エラーになることをテストしましょう
- トリガー
- トリガーを発動させ、それを確認するためのクエリを実行するシナリオテストをしましょう
- ストアドプロシージャ
- アプリケーションコードのユニットテストと似ている
- 入力およびデータの条件に応じたテストをしましょう
- ブートストラップデータ
- 初期データ確認のクエリを実行してテストしましょう
- クエリ
- クエリを実行し、結果が適切かを確認しましょう
- オブジェクトリレーショナルマッピング
- バリデーション等をテストしましょう
23.5.4 複数のブランチを扱う
アプリケーションの開発ではバージョン管理していると思いますが、データベースはバージョン管理の対象外です。
理想は、各ブランチ向けにそれぞれデータベースインスタンスを構築することです。
データベース接続パラメータが設定できるようにしましょう