読書メモ Design It! プログラマーのためのアーキテクティング入門

Design It! ―プログラマーのためのアーキテクティング入門

ざっくり概要

xxx It! 訳本シリーズ訳４冊目(原書は全７冊)。ソフトウェアの根幹となるソフトウェアアーキテクチャをいかにデザインするかを解説する本。 原題は Design It! From Programmer to Software Architect

第一部 ではソフトウェアアーテクチャとは何かについて解説し、第二部ではアーキテクチャを設計するために必要な基礎的な考え方を解説。 第三部では個々の詳細な方法論について解説しています。

参考になった箇所

全部を網羅できないので、私が参考になった、共感した部分を断片的に残します。

ソフトウェアアーキテクチャとは

望まれる品質特性やその他の性質を促進するためにソフトウェアをどう構成するかということに対する、重要な設計判断が集まったもの

デザイン思考

アーキテクチャを設計するにあたり、デザイン思考に則るのが有効。デザイン思考とは以下の４つの原則から成る。

1. 人間性の規則 全てのデザイン活動は究極的に社会的な性質をもつ。

2. 曖昧性の規則 デザイン思考者は曖昧性を保全せねばならない。

   -> 必要最小限のアーキテクチャ 目指す品質特性を促進するために、最小限の設計を行い、責任を持てる限り設計判断を遅らせる。それらは後続の設計者に委ねられる。

3. 再デザインの規則 すべてのデザインは再デザインである。

4. 触感性の規則 手に触れられるアイデアを作ることは常にコミュニケーションを促進する。

例えば、設計に関して言えば、設計は曖昧性を残し、設計を

デザインマインドセット

デザインマインドセットの観点からアーキテクチャを考える必要がある。デザインマインドセットとは以下の４つがある。

• 理解
• 探求
• 作成
• 評価

良い名前を使う(７Stage of naming)

"Good Naming Is a Process, Not a Single Step" という記事(?) において、名前づけは７段階あり、上のステージほど設計物の理解を反映している。

1. 名無し 名前がない状態
2. 無意味 名前に意味はないものの、つけられている状態
3. 的確 要素の責務について 少なくとも１つ表している状態
4. 的確かつ完全 要素の全ての責務を直接表している状態
5. 適切な行い 要素の責務を進化させるという意識的な決定が名前に反映されている状態
6. 意図 名前には要素の責務だけでなく目的も表わされている状態
7. ドメイン抽象 個々の要素を超えた新しい抽象概念が作成されている状態

所感

ここでは内容を断片的にしか書けていないですが、ソフトウェアの設計に関する知見を幅広くカバーしています。アーキテクチャパターンなど技術的なトピックから、ミーティングの開催方法などチームビルディング的なところまで多岐に渡ります。 自分は現在そこまで大きなチームで開発しているのわけではないので、本書に記載のあったチームビルティングやアーキテクチャのドキュメント化方法など、そこまで実感のわくものではなく、ほーそうなのねというレベルでしたが、プロジェクトの規模が変わると再度立ち返れば良いかなと思います。

日頃ソフトウェア設計をやっていれば、やっぱそうだよねと思う部分があります。上記の内容と重複しますが、取り扱う内容がかなり広範なので、何かしら得るものはありそうです。