本・業界の原典から
書籍を読んで要約したものと、web の一次情報源を取得して書いたもの。
どのページにも frontmatter に book: か、原典の URL と取得日 (fetched:) が残っている。
書籍由来の主張には (書籍11章) のように章まで注記してある。本文の引用はしていない。
プロジェクトの時系列に並べてある。 上から順に、始まる前・要件・設計・実装・ リリース後の変更・運用・廃止。同じ話題が複数の段階に出ることがある (アクセシビリティは要件で目標を決め、実装で確かめる)。
1. 始まる前
何を大事にするか、どういうチームでやるか。コードを1行も書く前に効く。
- ソフトウェアエンジニアリングとは何か — 時間・スケール・トレードオフ。書籍 第1章
- チームでうまく仕事をするには — 謙虚・尊敬・信頼、バス係数、批判の受け止め方
- 知識共有 — 誰に聞くか、書き残すか、心理的安全性
- 公正のためのエンジニアリング — バイアスと、誰のために作っているか
- チームリーダー入門 — マネージャーとテックリード、アンチパターン
- スケールするリーダー — 常に決断・常に離脱・常にスケーリング
- エンジニアリング生産性の計測 — 計測すべきか、GSM フレームワーク
2. 要件を決める
何を作るかと、どこまで満たせば良しとするかを決める。上限や目標はここで決める。 実装してから決めると、守れなかったときに直す判断ができない。
- 要求と見積り — ストーリーを会話として扱う、INVEST、見積りを何の判断に使うか
- アクセシビリティ — POUR の4原則と WCAG の適合モデル。どのレベルを満たすと決めるか
- パフォーマンス予算 — 測る前に上限を決める。CI で守る
3. 設計する
どこで切るか、どう壊れるかを決める。あとから変えるのが最も高くつく層。
- モジュール境界 — どこで切るか。切らない判断も含む
- 結合の度合い — 連鎖度(connascence)。結合の種類と強さ、弱い形への書き換え
- レイヤリングとドメインモデル — 層を第一の分割軸にしない。ユビキタス言語、境界づけられたコンテキスト
- デザインパターンの使いどころ — カタログとの付き合い方。「いつ使わないか」を要求する
- 分散システム — 壊れ方の設計。リトライ、期限、過負荷、カスケード障害
- Web API 設計の要点 — 『Web API: The Good Parts』の読書メモ
- API のヘッダーとアクセス数制限 — OWASP Secure Headers、RFC 6648、IETF RateLimit Header Fields
- 脅威モデリング — 設計時に何が起きうるかを洗い出す
4. 実装する
書く・見る・確かめる。この段階が最も本数が多い。
- スタイルガイドとルール — ルールを定めるときの基準。書籍 第8章
- バージョン管理 — 単一バージョン原則、モノリポ、トランクベース開発。書籍 第16章
- 継続的インテグレーション — CI は道具の名前ではない。10分ビルド、段階の分け方、壊れたら戻す
- 静的解析 — 書籍 第20章。機械が指摘できるものを人間に見させない
- 設定と環境 — 何を設定として外に出すか。12-Factor の対応表つき
- コードレビュー(書籍第9章) — 承認の3種類、恩恵、変更の種類ごとの見どころ
- テスト — なぜ書くか、いいテストの条件、何を・どこまで・どう書くか。書籍 第11〜14章
- ドキュメント — 存在意義、コードとして扱う、対象読者、5W1H、類型。書籍 第10章
- 守る側の設計 — 認証と認可、入力検証、暗号、秘密情報、サプライチェーンなど10本
- 実装時の検証 — キーボード操作、拡大、リニアライズ。満たしているかをどう確かめるか
- 国際化 — 文字コード、言語の宣言、文字方向、名前と住所の前提
- Effect を置かない判断 — React 公式。
useEffectでのデータ取得は推奨から外れた
5. リリース後に足す・直す
**動いているものを変える段階。**壊さずに出す方法と、出したものを測る方法。
- リリースとデプロイ — 密閉ビルド、設定管理、DORA の指標
- デプロイ戦略 — カナリア、ブルーグリーン、フィーチャートグル、影響範囲の制御
- スキーマ変更の運用 — オンライン DDL、メタデータロック、領域要件
- ユーザー体験の目標 — Core Web Vitals。利用者の側から見る
- 性能を測る — USE メソッド。資源の側から見る
- プロファイリング — フレームグラフ、off-CPU 分析。どのコード経路が時間を使っているか
- 負荷試験 — どこで壊れるかを探す。結果はキャパシティ計画へ渡す
6. 運用する
**動き続けている間の話。**壊れたことに気づき、直し、次に備える。
- 可観測性 — SLI/SLO/エラーバジェット、4つのゴールデンシグナル、ページの出し方
- インシデント対応 — 指揮の型、役割分担、非難しないポストモーテム
- オンコール — 時間配分の上限、ローテーションの人数、トイル
- キャパシティ計画 — 意図で書く、依存と性能指標、資源の割り当て
- データの完全性とリストア — 多層防御、レプリケーションとの違い、復元の演習
7. 廃止する
**終わらせ方。**始める前から決めておくもの。
主な原典
『Google のソフトウェアエンジニアリング』全17章 / 『Web API: The Good Parts』/ 『Site Reliability Engineering』/ 『The Site Reliability Workbook』/ OWASP (Top 10, Secure Headers, ASVS) / W3C WAI (WCAG 2.2) / web.dev (Core Web Vitals) / RFC・IETF ドラフト / Martin Fowler / Brendan Gregg / The Twelve-Factor App / DORA
同じ話題の自分のノートは 自分のノート にある。
ここにある規範のうち、実装を AI に書かせると自然には守られなくなるものは AI駆動開発のためににまとめてある。 とくにテスト（本物 > フェイク > スタブの順序が反転する）、 レビュー（変更の粒度が最初に壊れる）、 バージョン管理（戻せることが唯一のブレーキになる）。