女性向けエンジニアスクール
3秒でわかる
作るものの構造と分担を、コードを書く前に決める工程。後から直すと高くつく判断を、安く試せる紙の上で先に済ませるための作業です。
もう少し詳しく
どういうものか
設計は、要件として決まった「何を作るか」を、「どう作るか」に変換する工程です。画面の構成、データの持ち方、処理をどのモジュールに分けるか、外部システムとどうつなぐかを決めます。粒度によって呼び分けがあり、システム全体の構成を決めるのがアーキテクチャ設計、機能ごとの入出力を決めるのが基本設計、クラスや関数レベルまで落とすのが詳細設計です。
なぜ必要か
変更のコストは工程が進むほど跳ね上がるためです。テーブルにカラムを 1 本足す判断は、設計段階なら文書の書き換えだけで済みます。実装後なら、移行スクリプト、影響する画面、テストの修正が付いてきます。運用開始後なら、それに加えて既存データの補正が要ります。安く直せるうちに間違いを見つけるのが設計の目的です。
もうひとつは分担です。3 人で作るとき、境界が決まっていないと同じものを 2 人が別々に作ったり、どちらも作らずに落ちたりします。設計は作業を切り分けるための線引きでもあります。
具体例
設計の成果物は文章と図です。たとえば、注文機能のデータ構造を先に決めるとこうなります。
users ── 1 ─── n ── orders ── 1 ─── n ── order_items
│
n
│
1
products-- 決めた構造をそのまま定義に落とす
CREATE TABLE orders (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
user_id BIGINT NOT NULL,
ordered_at DATETIME NOT NULL,
status VARCHAR(20) NOT NULL,
FOREIGN KEY (user_id) REFERENCES users(id)
);金額を注文明細にも持たせるかどうかは設計上の判断です。商品マスタを参照するだけにすると、値上げした瞬間に過去の注文金額まで変わります。過去の伝票は当時の値段で残すべきなので、明細に単価をコピーして持ちます。こうした判断は、実装を始めてからでは戻りにくいところです。
つまずきやすいところ
設計を完璧にしてから実装に入ろうとすると、決められない項目で止まります。実際に動かさないと分からないことは必ず残るため、リスクの高い部分だけ先に小さく試し、残りは実装しながら決める形が現実的です。
逆に、設計を飛ばして書き始めると、動くものはできてもデータの持ち方が歪んだままになります。特にテーブル設計は後から変えにくいので、ここだけは先に紙の上で確かめます。
