親: Design it を読んだ - t_hazawaの日記
これは
- Design it! の1～6章を読んだ時のMEMOです。
凡例
- 2～3桁の数字はページ数
- 横文字はひたすら情報密度が低いので、最後の1,2文字だけ読むと楽
- 最後なのは、日本語の名詞は後ろの格助詞とくっつく(膠着する)から
- (ブログに載せることを想定してなくて)下から上に書いていってるので、章ごとに下から上方向に読むと読めると思います
1章
設計の心構えなど
1.2.2 (演習) モジュール: 階級クラスは(階級の)ネーム Attributeを使う コンポーネントやコネクタ: httpdのマスタープロセスがワーカープロセスをつくる 割り当て: Lbがリクエストを受けてサーバーにわたす 演習も、本当に簡単に取り組もうかななう(2020/12/30 20:20:43) 実践的なアクティビティ(アーキテクチャを作るために使える取り組み)が 38あって役立ちそうかもなう(2020/12/30 22:35:42)（目次） しかし、タイトルだけみると、既にできてるのも結構ありそうなう(2020/12/30 22:42:51) 1.1.5技術的負債がどのくらいコストなのか明示できるといいねなう(2020/12/30 23:10:08) なう(2020/12/29 16:44:27) できるだけ設計を後回しする Twitterはrailsで始めたが、2009年にjvmになった viii アジャイルでは偉いアーキテクトはおらず、現場でアーキテクチャを選ぶらしい xi 人が第一義xiii
2章
どのようにアーキテクチャをデザインするか (早く読む方法に夢中)
2章 19 デザイン思考は人間に注目するなう(2020/12/31 19:52:07) 解決すべき本質的な問題に集中なう(2020/12/31 19:52:36) デザインマインドセットなう(2020/12/31 19:54:26) 20 hart 人間、曖昧、再び、触れる …がデザインのコツ4つ ソフトウェアアーキテクチャとかカタカナ語がひたすら長いなう(2020/12/31 19:37:48)コミュニケーション チャとトでよい（湯婆婆並感）なう(2020/12/31 19:41:14)（湯婆婆メソッド） ソフトウェア → ア ソフトウェアシステム → 厶 デザインマインドセット → ト プラクティス → ス ステークホルダー → ダー トレードオフ → フ デザイン → ン デザインスイートスポット → ト、ントト 16 重要な設計判断}…重要かどうかは変更コストによって計られるなう(2020/12/31 19:40:36) 23(湯婆婆メソッド) 厶の設計では、異なるトの観点からチャについて考えなかん （25モじ） ソフトウェアシステムを設計する際には、異なるデザインマインドセットの観点から アーキテクチャについて考える必要がある。（53文字） トは理解、探求、作成、評価 (デザインマインドセット) 23 (湯婆婆メソッド) チャの設計ではトを選び、トのスも選び、そのスを適用することでチャについての新たな学びを得る…事を繰り返す （48字） アーキテクチャを設計する際には、マインドセットを選択し、そのマインドセットのプラクティスを選択し、 そして、そのプラクティスを適用することによって、アーキテクチャに関する新しい学びを得るということを繰り返す。（95文字） 31 2.4 ここまでが理論だったなう(2021/01/01 19:43:04) 30 プロトタイプ推しだけど、プロトタイプがどれくらいのものか実例を見せて欲しいなあ 後ろに書いてあるかもなうあなう(2021/01/01 19:11:21) 書いてなかったら、自分で調べる 29 こういう仮説検証サイクルは日頃やってることのような気がするなう(2021/01/01 18:08:55) なう(2021/01/01 17:17:14) トを切り替えることで轍(わだち)、袋小路から抜け出せる デザインマインドセット なう(2021/01/01 17:17:34) なう(2021/01/01 16:58:25) 2.3 学び方の話。TDCサイクル PCDAと大体同じ なう(2021/01/01 16:09:46) 2.2.5 理解 数字を集めてR 探求 思いついたのをカラーノートに書いてるよ 良さそうなアイデアははいいところわるいところリストにして比較するよ 作る 作ったものがよく動いてれば人は着いてくるよ 評価 汚いが問題は解決できてる 作る前ならやっぱイメトレでよしよし上手くいくなとかここで詰まるなとか 通しで想像してみるなう(2021/01/01 16:12:08) （シナリオウォークスルー（ルー）） なう(2021/01/01 15:35:08) 作成をするとチームは分析麻痺から抜け出せる なう(2021/01/01 14:50:21) トにおけるスとは、例えば探求だとグなう(2021/01/01 14:50:47) デザインマインドセット プラクティス ブレインストーミング なう(2020/12/31 20:16:24) 22 以前からあるソフトウェアシステムを無視するというのはチャ設計で最も効果が薄い (re-design) もとがPHPだったら、railsじゃなくてlalavelの方がよかったのかも。(モデル使いまわし) なう(2020/12/31 20:06:14) 9 要素と関係の一覧は初めて意識するかもなう(2020/12/31 18:09:42) モジュールは設計時の要素を表すものであり、コンポーネントは実行時の概念を表すものだ。 言葉を正確に使うことは、時に重要な意味を持つ。そのために作られた「用語」は明確な意味を持つ。 アーキテクチャの一般的な構成要素を示したいときには、コンポーネントやモジュール という言葉を使う、みたいな
3章
設計の勘所
46 3.3.3 アクティブデザインからパッシブパッシブデザインへ なう(2021/01/02 18:12:17) 43 リスクステートメントは、「今日の事実-未来の結果」形式 で書こうねなう(2021/01/02 16:10:22) 「いま膝が痛い - ので、明日は歩けないかもしれない」 41 cosysmo見積りモデルというものがある。 なう(2021/01/01 23:54:15) cocomoというものもある 39 過去の事例のデータで、どのくらいの時間設計に当てればいいかわかってよいなう(2021/01/01 23:38:49) 10000ギョウナラ1% 10万行なら20%1000万行なら37% 設計すればリスクは必ず減るなう(2021/01/01 23:45:39) 変更が予想される時にはより軽量な文章の方法…？なう(2021/01/01 23:46:28) → これは10章付近に書いてあった(部族的な方法) (先を読んだ読者より) 36 3.2 早く学び早く失敗しようなう(2021/01/01 21:45:06)
4章
要件定義の勘所
51 4章ダーに共感 ステイクホルダーなう(2021/01/02 19:55:02) なう(2021/01/03 18:46:52) 演習4.3.3 バウンシング 客 見込み客 お得や便利 使われない 完成しない なう(2021/01/03 16:20:16) 59 ビジネス目標には「あると良い(あったらベター)」レベルの目標もある (必須ではなく) ダーにはズの必要がある。なぜなら～ ズ=ニーズ=◯◯といったニーズ そのズを満たすのはダーの責任で厶は手助けするだけなう(2021/01/03 16:23:44) 演習4.2.1 やまぶき ない 作った人 本人 楽に打てる、飛鳥配列の人はデファクトになってハッピーなう(2021/01/02 20:54:38) 54ダープは経験的にできるだけ詳しくするといいよ ステイクホルダーマップ 矢印の多いネットワークハブ の人が重要人物 53 インタラクティブなプロトタイプ推しだけど、その具体例がこの後出ることを期待 (出てこなかったら調べる)
5章
- 要求の定義の仕方
5.6重要な要求ワークブックなう(2021/01/04 19:24:50) 項目に用語集がある(用語集をつけるのはとても重要) この本を読む目的：アーキテクチャ的なことを学ぶ アーキテクチャパターンとか？ なんか違う気がするぞ！？ 確かに。アクティビティとかは参考になる気もするけど、もっとアーキテクチャパターンを知った方がいいかもね (この本には10個くらいしか載っていない) なう(2021/01/04 00:49:13) 72 要するに、クリティカルじゃないところ（機能）は既存のもので埋めれる、推定できるだろうということ この5章でトは「要求エンジニアリング」をしている（要求グ） アーキテクト なう(2021/01/04 00:38:51) 演習5.2.3 刺激 発生源 成果物 応答 応答測定 環境 いつも通りの機材環境で テストプログラムが Rep一覧をリクエストすると システムは Rep一覧を 予期したセットで返す 信頼性 ユースケース → ス ユーザーストーリー → リー ASR アーキテクチャ上重要な要求(繰り返し出てくる言葉) なう(2021/01/03 20:25:39) 65 市がオープンソースを求めることは実際にあるのかな アメリカは？IEではなくFirefox？ 確かにchromeより公共そう なう(2021/01/03 19:01:24) 5章 要望への応え方
6章
作る目標の決め方(満たすべき品質目標の決め方)
なう(2021/01/05 22:19:11) 96 SOLID原則を説明的な名前にしたらなんだったかな (私物のGoogleドライブに残してあった SOLID原則 でGoogleドライブを検索) 単一責任原則 拡張開放・変更閉鎖原則 (← 開放閉鎖原則) サブクラスに置換可能原則 (← リスコフの置換原則) (サブクラスを変わりに使っても動作するという原則) インターフェイス分離原則 抽象依存原則 (← 依存性逆転の原則) (素朴にやると実装に依存してしまう) 「リスコフ」は頭文字をSOLIDにするために付けられてる感 6.5.2 責務を分割して交換出来ればもはやASRではない なう(2021/01/05 19:33:18) 87 スムージー 88 ブレンダーの品質特性6項目 パターンとは？（この次の項目に詳しく書かれる） 89規則チェッカー？ サービスレジストリ？ 7章で説明されるらしい どのサービスを利用できるかをチェックできるレジストリ(サービスに分けるチャパターンで使われる) 3層パターンは拡張性や可用性が弱点なう(2021/01/05 20:23:26) 急峻なインフラストラクチャ曲線？（サービス志向チャ） 小さい規模でもたくさんインフラが要るということだろう(その後は穏やかな上昇勾配) やりすぎになる可能性があるらしいなう(2021/01/05 20:30:34) 6.3.2 意思決定マトリクス 項目別に重視するやつを決めるのだろうなう(2021/01/05 20:31:35) なう(2021/01/05 12:07:55) 86 ダーは制約がチャに与える影響を理解してないかもなう(2021/01/05 12:08:14) 話し合おうね なう(2021/01/05 11:35:46) 85 急ぎの時はチームが精通している技術を選択する なう(2021/01/04 20:54:05) 83 確かにこの本はスコープ広いかもね 我々にはRailsで大体は解決出来るような問題しか来ないのではないかな ので、web開発に絞ったアーキテクチャなりなんなりの話だともっと直接的に役立つかもなう(2021/01/04 20:55:06) → でも、後半読んでみると、そういうWeb的問題でも使えそうな手法が載ってそうで楽しみ 2021/01/13 16:53 構築方法やデプロイ方法も過去確立したものがそのまま使える的な。 で、部分的に新技法を取り入れていくみたいななう(2021/01/04 20:56:38) でも前のパーフェクトRoRは超具体的だったので今回はこれくらい抽象的でもいいのかもなう(2021/01/04 20:57:10) なう(2021/01/04 19:21:49) 77 Aの発言が終わった時だけ、聞いているBは問いかけられる（アクティブリスニングのやり方） 『人を動かす』 カーネギー 79 品質特性シナリオ（オ）はこの例でも240もある そのうち大事な7つをちゃんとやるらしい
