■ 1. 設計を体得できていない状態とは
- 問題の本質: 設計が何か分からなければ設計はできない
- 教える側と教わる側のすれ違い:
- 教える側は「図や表を通じてシステムを考えられる」と考えるが、教わる側は「システム=コード」と捉えている
- 教える側は設計によって重要な課題が洗い出せると考えるが、教わる側はコードが分からないと課題も分からないと感じる
- 設計していないことに気付かない問題: 初学者は「DB→モデル→コントローラ→ビュー」という手順を説明するだけで設計したと思い込む
- 手順による実装の実態: 実装前に全体を考えず、マイグレーションから作業を進めて最後に何を作れたか理解する状態
■ 2. 設計の定義
- 設計とは: コードのレベルで考えることなく、全体としてどういう構造や技術的要素を使ってどんなものを作るのが良さそうかを考え、作業の段取りを考えても良い状態にすること
- ベテランと初学者の違い:
- ベテランは抽象度の高いレベルでシステムをまず考える
- 初学者はコードのレベルだけでシステムを考えがち
- 設計は手順の前に来る: 手順を考える前にシステムの構造を考える必要がある
■ 3. 逆算による設計メソッド
- 順算との対比: 従来の「手順による開発」をまだ見えないゴールに向かってコードを順番に作る「順算」に例える
- 逆算の流れ:
- まず完成したシステムを思い浮かべる
- 中核的な「実現したいこと」にフォーカスする
- 「それには何が必要か」を順々に考えていく
- 目的: 設計がよく分からない人を設計世界へ導入する手法である
■ 4. 実践例:ユーザーCSVインポート機能
- 完成形の想像:
- 大量登録時の時間やメモリの問題を想定
- 一部エラー時の処理方針を検討
- エラー情報の表示方法を検討
- インポート履歴の必要性を検討
- 課題の洗い出しと仮置き:
- 非同期処理にすることを仮置き
- 全部失敗方式を仮置き
- Importモデルでエラー情報と履歴を管理
- ゴールの設定: 実際にCSVからユーザーが登録・更新されることを本質的なゴールとする
■ 5. ステップと名前付け
- ステップの定義: 見つけた「実現したいこと」「必要なこと」に短い名前をつけて形を書き出す
- 名前付けの重要性:
- 設計は大きな粒度で考える活動である
- 長い概念を短い名前に置き換えることで脳内スペースを節約できる
- 設計は名前をつける行為の積み重ねである
- 具体例: 「インポートすること」自体をモデルにしてImportと命名する
■ 6. 開発領域の整理と手順計画
- 領域分け: 処理の順番や処理が書かれる場所の違いに注目して大まかにグルーピングする
- 手順の考え方:
- データが準備しやすい流れを考える
- 本質的なこと、難しいことをなるべく先にやる
- 設計後の手順の質の変化: DB→モデル→コントローラ→ビューではなく、Import登録→インポートロジック→一覧・詳細といった機能単位の手順になる
■ 7. デザインパーツの活用
- デザインパーツとは: 再利用性のある小さな設計パーツで、アーキテクチャや考え方を指す
- 主要なカテゴリ:
- データ構造(ActiveRecord、関連、制約など)
- 処理構造(MVC、コールバック、非同期処理など)
- 個別機能・Gem(認証、認可、検索機能など)
- 効果: 色々なデザインパーツを理解していれば速く妥当な設計ができる
■ 8. 今日伝えたいこと
- 全体が機能するように設計する: アプリケーションだけでなくシステム全体が機能するように設計することが重要である
- システムコンポーネントとパターンの組み合わせ: パターンを組み合わせてシステムを構成することで全体の構造が現れる
- 初学者向けの手法: 完成形をイメージして中核的な価値の実現から逆算で1つ1つ要素の形を決めていく