日記「『Design It! 10章設計判断を可視化する』を読みなおした」

この本『Design It!』は、すでに一度読んだことあるけど（といっても第Ⅲ部はほとんど読んでない）後半はとにかく読み終えなきゃという気持ちが強かったので中身の理解が半々ですぐに忘れてしまった。前半も時間が経ちすぎてあんまり覚えてないので最近気になったとこを読み直し中。内容も難しいので、メモとしてここに残しておきます。

読書メモ

アーキテクチャの詳細を一つの図で捉えることは不可能
- 複数のビューを作成する
  - ビューとは、特定のステークホルダーまたは一連の関連する関心事の観点から語られたアーキテクチャに関するストーリー
- ソフトウェア・システムを説明するためのビューは、Google マップのように様々な視点から見れるようにする
要素責務ビュー
- 要素と責務が一覧できるビュー
- プロジェクトによってはこれだけで済む
- 基本的には情報が欠けているので、注釈や表形式、説明文などを記述して責務を説明する
絞り込みビュー
- 一部の要素の詳細を表示するビュー
- 詳細度によってはモジュールごとの関係や保守性について知ることができる
  - 例えば、一部のモジュールが相互に依存しておりそのモジュールのテストがしづらいなど
品質特性ビュー
- アーキテクチャが特定の品質特性をどう実現するかを示す
- 例えば、可用性を示す場合は、冗長パターンがビューで示される
アーキテクチャのラフスケッチ
- 精密さには欠けるが素早い反復と形式張らないコミュニケーションには有用
  - また、自分のアイデアを膨らませるためにも使える
- 設計が固まってきたら正確なモデルを描く
素晴らしい図は、アーキテクチャを誰でも触れられるものにする
- 素晴らしい図を作成するためにすべきこと
  - 図に関連するメタモデルを要約した凡例を作成する
  - 説明的なタイトルを追加する
  - テキスト注釈を追加する
  - 表記法を一貫する
  - パターンをわかりやすくする
- 素晴らしい図を作成するために避けるべきこと
  - UML のような表記法を知っていることを前提にする
  - すべてを一つの図に含める
  - 白黒で印刷すると意味がなくなる書き方をする
  - 意味のない飾りや多種多様な形、線を使い過ぎる
  - 説明文を省略する
- 叙述的散文でアーキテクチャについてのストーリーを語る
  - 物事を客観的な説明によって順に並べた文章のこと
  - 11 章で詳しく説明される
図を上手く描いて、上手く使えば、アイデアを発展させることができ、ステークホルダーとの共有もできる。
- また、品質特性についての設計判断を行うことができるようになる
6 章や 8 章を理解しておくと理解が深まりそう

感想

この本を読んでから、品質特性について意識しないといけないという気持ちが強まっているので、図から品質特性の設計判断ができるのは勉強になった。見方に合わせて図（ビュー）を変えるのは何となく分かっていたつもりだけどこれを読んで腑に落ちた感じ。

最近は最初の設計段階では紙に書くことが多く、人に説明する必要が出てきたり、考慮すべきことが増えてきたらツールを使ってビューを作ってる。ツールは、VSCode で使える Draw.io の拡張機能が手軽で便利。昔は PlantUML で書いてたけど、最初に使うには手軽とは思えないし、モデルの配置が思い通りにいかないので使いづらい。状況によっては PlantUML を使うのがいいのかもしれないけどあまり思いつかない。

詳細度を変える話で、設計ドキュメントをまとめておくときにフォルダ構造を詳細度に合わせるといいのかもなと思った。深くなれば詳細になっていくようにしておけば、何も知らない人は知りたい詳細度に合わせてドキュメントを探しやすい？

marketplace.visualstudio.com

おしまい