日々の破片

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

Design It! の続き。

付箋紙を貼ったところを中心に（読まなければなんだかわからないメモも含まれる）

P.76「5.5 必要な情報を掘り下げる」ここで本書を通じて一番のキーワードである「ASR（アーキテクチャ上の重要な要求： Architecturally Significatn Requirement）」について掘り下げかたの説明がある。

なにしろアーキテクチャデザインの本なので、当然のようにアーキテクチャ上の重要な要求を最重視するのは当然だ。

とにかく本書を通じてASRという言葉が飛び交うのだが、頭語としては別の意味がおれには馴染み深いのですぐ本書の定義を忘れてしまうので、このページに付箋紙を付けて良かった。

P.106～P.107 すごくわかりにくい。

抽象的かつ複雑かつ広範囲にわたる概念（SOA）を2ページで説明するためにNetflixのスマートエンドポイントとパイプアプローチを具体例としているのは良いのだが、図7.4がNetflix固有で確かにP.106には「ある視点から見たとても単純化したサービス指向システムの例」としているのだが、表7-4を読み終わった後にはそれを忘れて「はてレーティングとは？ Eurekaとは？」となって混乱した。

P.109 表7-5 いきなり「C&C構造」というのが出てくるが、P.9の「コンポーネント&コネクタ」のこと。時々あまり馴染みがない用語が飛び交う。

P.113 7.9コンピタンスセンター（なのだが略語はCoCとなる）パターンはすごくおもしろい。

P.117 7.12 新しいパターンを発見する。

2つ書いてある。問題重視アプローチと解決策中心アプローチ。おれは圧倒的に問題重視アプローチをとることが多いが、複数の問題に対して一般的な解決策を探すか、複数の同じような解決策から共通の問題を求めるかで、演繹と帰納に相当するのではなかろうか。

実際には、3回実装して共通点からライブラリなりミニフレームワークなりにすることが多いので、（設計段階では）問題重視アプローチをとっているのに、実装時には解決策中心アプローチをしているようだ。

P.155 「タンジブル？」という付箋紙がはってある。

有形資産をカタカナでタンジブルと書く（辞書にも出ている）のだが、おれには意識した人生初出語だった。

どうも使われ方、ニュアンスからは、「見える化」と同義のようだ。

P.156「信頼の薄い仲間」というのがおもしろい。

箱と線は、アーキテクトに最も使用されている道具だが、最も信頼が薄いと書いてあっておもしろがっている。

P.165 最初に凡例を書くのは良いアイディアだ。（10.2.1 凡例を使う。ただ凡例を含めるだけではダメ）

ユースケースのアクター探し、伝統的OODのオブジェクト探しとして図には凡例がある。

P.166 表記法はなんでも良い。UMLが共通といっても知らない人のほうが多いのだ。だから、とにかく読み手を考えて凡例を書け、と強調していて、なるほど感。

P.177 アーキテクチャデシジョンレコードという言葉が唐突に飛び出す。はて？ と思って索引を見ても出ていない。索引ではADRとなっている。

（時々、このようなぶれがある。ところどころでは「頭語（説明）」と親切表記になっていて、ところどころではいきなり「頭語」おしまい、となっているのだが、筆者が頭語好き過ぎで混乱しているように感じる。いかにもアーキテクトっぽいが、だめだろうなぁ。凡例重要でしょうに。

P.180「11.2.4 時間を無駄にするのを避ける」

良いアーキテクチャ記述（おそらくすべてのプレゼンテーションに関わる）に対する4つの特徴。

・聴衆

・マルチビュー

・責務

・根拠

これらが揃っていないとお互いに時間を無駄にする。

P.188 メモ：「選ばなかった理由←知識が求められるのでは？」

選ばない理由は山ほどあるので、それを明示しろとあるし、それは多分正しいと思うのだが、それが山のようになることと、選ばなかった捨てる判断のための説明をするのはあり得ない（相手に知識がない場合）というおれの感想。

P.192 「タンジブル？」また引っかかっている。

P.195 「ルーブリック？」綴りが無いので調べるのに死んだ。rubric。タンジブルと違ってカタカナ日本語にもなっていない。本文に書いてあるとおりに「観点と尺度からなる表」ととらえれば良いのだが、訳語は「朱書き、注釈、指示、説明書」らしい。P.196のルーブリック例を見るとなんのことかわかるが、独自用語っぽい。

P.207 色がついた。実は本書はカラー本だった。

P.214 「13.1 アーキテクチャ思考を促進する」に対して付箋「良い！」

なのだが、P.215には「悪くない⇒悪くない」と付箋があって、今見ると意味がわからん。良いことが書いてあるのは事実だ。

P.219「設計権限を委譲する」 権限移譲のためのレベルが7段階（指示から委譲まで）書いてあっておもしろい。良いコードのようでもある。tell don't askだ。

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