親: Design it を読んだ - t_hazawaの日記
7章
よくあるアーキテクチャパターンを12個ほどご紹介
なう(2021/01/06 21:10:53) 114 コンピタンス 期待に応じることが出来る能力 CoCチームは会社にたくさんあるねなう(2021/01/06 22:55:46) RDB専門チームとか 108 チャの前提に一致する技術を選ぼう なう(2021/01/06 19:50:08) 106 SOAP はサービス志向アーキテクチャプロトコルだったのね なう(2021/01/06 18:41:51) 103 C&C構造 コンポーネントアンドコネクターか (前に出てきた言葉) なう(2021/01/05 22:42:29) 7章 本来知りたかったアーキテクチャパターンについて書かれているようだ（略してチャン）
8章
決定したアーキテクチャを後世に伝えよう
なう(2021/01/08 20:56:07) 132 c&c や マイクロサービス化してコンポーネント化すれば、使用に関する規約を強制できる PaaSはIaaSとSaaSの間。RDSとか コンテナもコンポーネントごとに別れてるので、接続部分で使用規則を強制できるね githubも書き込み提案を許可しつつも書き込み制限をできてるよ（使用規則を強制できてる）なう(2021/01/08 21:23:25) 133 コメント内のドキュメントへのリンクはいいぞ なう(2021/01/08 20:10:17) 演習 8.2.5 セル（生き死に状態を持つ、グリッド位置を持つ） 繰り返し 過疎 生存のまま 過密 誕生 →セル変化(命名の進化) 的確かつ完全 → 適切な行い グリッドに他のものが来ないか気になる 今のところはないよ マス (という概念ができるかも) なう(2021/01/08 17:54:12)今日は チャプク アーキテクチャフリップブックなう(2021/01/08 18:00:56) チャの変化と選択の過程集 (チャプク) 自分は過程は（やたら詳細な議事録に）残してるけど フリップブックみたいな見やすい形にはしてない フリップブックは多分みやすいのだろう 思ってたのと全然違った（だいぶアクティビティだった） フリックブックを作っていって、適切なチャを探すというティ と思ったが、最後に大事なところを要約してたなう(2021/01/08 18:13:06) 8.3モデル（チャ）をコードに埋め込む方法なう(2021/01/07 20:24:12) チャの名前をコードでも使おう なう(2021/01/07 14:01:00) 119 8章 長らく探求の章だったが作成の章になった インターフェイスを書くところではそれだけを書くと記述がシンプルになるなう(2021/01/07 14:30:03) 詳細を隠す 実験は後で失敗が分かるよりは低コストらしいなう(2021/01/07 14:33:10) 1時間の設計が1ヶ月のコーディングに相当するなう(2021/01/07 14:58:08) 127 名前つけの7段階なう(2021/01/07 19:05:34)
9章
チームでアーキテクチャを考えるやり方
なう(2021/01/09 20:48:30) 9.5リモートワークショップ （トプ） パーキングロット（別のことを端に書いとく） 教えられなくてもできてた box.com 共有サービスなう(2021/01/09 21:32:40) なう(2021/01/09 20:16:25) 集団思考は、プの目的達成でなく、調和と合意を心配して良くない（有害） ワークショップ なう(2021/01/09 19:07:00) 145 やはり大切なのは「次にすること」をはっきりさせること 9.2.1 スケッチ（アーキテクチャ図を作る）の 実践・日頃からの練習 は飛ばしたなう(2021/01/09 19:09:08) 日常的にアーキテクチャ図をスケッチしてみよう、という演習問題だった なう(2021/01/08 22:59:07) 141 プでは目標を念頭に置くのが大事 ワークショップ なう(2021/01/08 22:00:07) 137 9章 チャンオ アーキテクチャデザインスタジオ シャレット(フランスの建設学科の荷馬車) 制限時間内でできるものが限界なう(2021/01/08 22:08:30)
10章
アーキテクチャの視覚的な描き表し方
なう(2021/01/10 23:05:06) 演習10.2.5 コンテナとコンポーネントがわかる コンテキストも少しわかる クラスはさっぱりわからない 多層 メタモデル…DBとかwebサーバとか？それならわかる メタモデル…記事とかそういうことらしい そこまで細かくは無いのでわからない (この前書いたニュースオリジナルの構成図) 単純化もできる かなり詳しいので(←俺は詳しいんだ的な意味？) なう(2021/01/10 21:06:19) 164 タイトルをつけられるテーマのある図をかこう なう(2021/01/10 21:06:34) 図にはタイトルをつけようなう(2021/01/10 22:27:55) C4モデル コンテキスト→コンテナ→コンポーネント→クラス とズームして言って図にかけるよ (棒銀的なテクニック) 箱の中に説明を書くのがオススメ 168 チャパターンがわかるように図を書こうね 図にはストーリーをつけるなう(2021/01/10 23:03:18) なう(2021/01/10 17:55:12) Marathon ... kubernetesの仲間 スティッキーセッション Cookieでクライアントを特定のサーバに結びつける AWSにある 表もビューの一種 161 考えが収束に向かったら正確にしていこうね それまではラフくて良いなう(2021/01/10 20:37:20) なう(2021/01/10 15:35:56) 接続が多いとテストとデバッグが難しくなる158 モデルやユーティリティはどこからでも接続だから図から省くのも手なう(2021/01/10 16:09:44)みやすくなる 必要なところまでで詳細化をやめよう なう(2021/01/09 22:02:26) 10章 チャ図を書く方法 複数のビューで描こうね Googleマップ的な見せ方(色んなレイヤーがある)
11章
アーキテクチャを文書にする
なう(2021/01/11 19:40:16)
179 まず目的を書こうね チャの記述もDRY
チャは大きいのでひとつの図では描ききれない(完全に記すには複数の図が必要)
◎最低でも用語集は必要（用語集推し）
180 前のシステムの引き継ぎ資料は確かに最初に項目を決めて、分担して書いたなあ
(最初に書くことを決めて、誰がどこを書くかを決めて分担して書こう、とDesign it にも書いてあった)
設計判断の根拠（資料に必要な4つの物 聴衆念頭・複数ビュー・要素の責務・設計の根拠）
が散りばめられたアーキテクチャドキュメント
182 読まれるチャ記述を書くのが大事
184 見栄えがいいと安心感が高い
185 ダーが知りたいことを書こう
ADR アーキテクチャデジジョンレコード チャンド
コードのコメントに設計根拠を書くのもいいぞ
187 著名なュートトがあるよ どういう視点で書けばいいかのセット
ビューポイントセット C4モデルとか（C4モデルは将棋で言う棒銀 これ一つ知ってれば結構戦える）
context contenner component class (の大きさでチャトや図を書く) アーキテクチャドキュメント
特定の品質特性を満たせることを示すためにビューポイントを設定することも多い
学習容易性のビューポイントのもとでは、チャの学習が容易になるようにまとめページを書くなう(2021/01/11 21:56:55)
規制のュートでは規制についての観点でまとめを書く
ビューポイント＝まとめページ
なう(2021/01/11 13:57:30)
173 チャトは大事 アーキテクチャドキュメント
174 すべてのダーはチャを理解する権利を持つなう(2021/01/11 16:52:10)
チャが分かると品質特性が分かる（のでどのダーもチャを知りたい場合がある）
チャを描くことはコードを書くより早いので早期に評価できる（できてる）
今日も「簡単なまとめ」でチャを先に示せたね(簡単すぎた) 2021/01/14 17:35
チャトで 目的・計画・ビジョンが明確になるなう(2021/01/11 17:06:43)
175 チャの記述方法は変更頻度で変わるよ 共有の必要度合いでも変わるよ
部族的な方法もスタート段階ではいいよ 変更しやすいよ
176 この辺りの話面白い（チャの記述について） 共有はむずい
２、３人以上に伝えるなら伝え方を進化させよう 詳しくはティ20らへんで
アクティビティ
形式的なトが必要な時でも、部族的な方法から始めるのが大事とのこと(変更が容易)
最初は変更が多いからかななう(2021/01/11 17:34:33)
チャが融合し始めたりダーに求められたらかっちりしたトを作る（必要な場合に作る）
伝統的なSAD アチャト は作るの大変だけど見合う価値はある（が必ず要る訳では無い。必要な時に）
ソフトウェアアーキテクチャドキュメント
なう(2021/01/10 23:09:26)
11章 チャの記述
188 選ばなかった道と理由が書き残されてると後続の人にわかりやすいよ
「この決定は後でも戦略を変えることができる」(コンテナ化しなかった判断に添えた文章) みたいに書いてあると後続の人に役立つよ
SQL DBに比べてSolrとかは検索できる入力クエリが幅広いというか、色んな検索ができる
演習 11.5.2
実況で「これはこういう理由でこうする」「これはこういう理由でこうしない」とあった
引き返せない判断はめったにない (いつも引き返せる判断をしてる)
…ので、割と速度重視で突っ込んでいってもいいかなと個人のプロダクトでは思ってる (最近慎重にしすぎてる感じがする)
190 ADR (チャンド)は後から知るのに便利
アーキテクチャデシジョンレコード
後半になると変更が少なくなるのでしっかりしたトを作りやすい
ドキュメント
12章
アーキテクチャを評価する方法(通知表をつける)
12章 P.191 チャに通知表をつける アーキテクチャ
手遅れになる前に改善できるのが通知表
チャの評価は設計完了タイミングだけじゃないよ
承認の儀式も、引き返せないタイミングだと大きな意味があるよ(契約とか調達の前とか)
チャが間違ってたら、全てが失敗したり、実装も始められないわけじゃないよ
個人のやつも引き返しはできるのだから、ガンガンやっていいかもね(変更するコストが低い)
よく出ることば ASR アーキテクチュラル シグニフィカント リクアイアメント
これを満たせているほどいいチャだよ
12.2 チャのテストをする
評価するには実物が必要だよ
ついにプロトタイプがどれほどのものかが示されるのか！？
最初にでてきた例: ホワイトボードスケッチ や 完全なるチャ記述
やはり、この前書いた「簡単にいうと」(jmeterの代替手段)と同じくらいだった
やはり手書きスケッチからコードを書いたものまで 様々だった (そのようにdesign it に書かれていた)
アーキテクチャ俳句(ティ21)推しな著者
「品質特性がどのコンポーネントで促進されてるかを示す 『ユーティリティツリー』」
P.193の真ん中まで。今日は大変だったので量的にはかなり少なめ
195 チャにおいて、要素間の関係は大事(図に書いた時の線)(軽視されがち)
196 項目表(品質特性の)を作ってチャを評価する
197 尺度の多さについて 4段階までが適切だよ
199 この本の後ろの方にはいろいろなティが載ってて(37以上)楽しそうだ アクティビティ
演習12.2.4 は日頃 その案件の●謎 を手元にかいてやってるのでいいや
202 評価には青果物が必要だよ(チャ記述とかテスト結果とか)
203 シナリオウォークスルー(オクルー)推し
204 評価クプをすると、どう改善すればいいかも分かる(こともある) ワークショップ
205 良いチャは変更が容易
ATAMという、重量だがしっかりできる方法があるらしい チャトレードオフ分析法
206 (自動)テストは実行コストや維持コストが安いのがオススメだよ 基本的には
でも、複雑な重い統合テストをしないといけないこともあるよ
そんなわけで、チャューも軽いのがいいよ(頻繁にやるやつは) チャレビュー
深い評価は、1,2回、対象を絞って深めの評価を数十回、クイックチェックを数百回以上する
208 虹を食べると健康的(色とりどりの野菜など) チャも虹を食べよう
課題の虹 色んな種類の課題がある
リスクは条件と結果(3.3) 今の条件と未来の結果
209 未知の未知はチャを殺す
設計のチャと実装のチャにはずれ、侵食、横滑り、腐敗が生じる
コードやトの細部に定期的に注意を払う ドキュメント
210 チャ評価を次に進めるには、まだされてない質問をして様々な課題を探る
低セレモニーな方法も(特定の特性品質上の問題,課題について)質問
211 チャ評価も低セレモニーな、軽い方法から慣れていこうね
プでもNext Action が大事 (ワークショップ)
213 13章 アーキテクトちから
FaaS (ファンクション)もあるよ
いまでは開発者みんながト アーキテクト
214 書かなくて皆が理解できるならトは少なくて済む ドキュメント
開発リーダーはチームの数歩先を歩いて メンバーを罠や落とし穴から遠ざける
215 自分もトの端くれ
ムでチャを設計しよう(ムにチャを設計させよう) チーム
ントも徐々に成長するといいよ ドキュメント
216 判断で満たされたントはメンバーにューしてもらおう レビュー
217 教育では足場を作って上げるといい 2021/01/17 15:04
設計の範囲を限定するガイドレール 設計をシンプルにするために使う
チャを台無しにしてしまう危険性が減る 設計ポリシーなど
コードに組み込まれてたりもする
2人ューしないとマージできないとか、CIの自動テスト通らないとダメとか
(ガイドレールの強制の例)
CIの自動テストを流さないでいるとズレたり侵食したりするわけね
218 ムがチャの問題点、改善案を出すようになってきたらいいね
自分も監視面では出せてるかもね(grafanaで全ログ見るやり方とか)
219 権限の7つのレベル
指示 説得 相談 合意 助言 尋ねる(ムの判断の理由を尋ねる) 委譲
13章
アーキテクトとして成長しよう
13章 トちから P.220 から 5.5ふん
220 確信が持てる部分の権限をムに委譲しよう 7分
いまは技術進歩が早いから技術リーダーが全ての技術を把握するのは難しいよ 8分
221 コミュ力(技術的ビジョンやチャの説明・説得や傾聴力)がいるよ 10.5分
チームを育てていくと(1人じゃないので)たくさんのことができるようになってよい 11分
222 ムが経験を積んできて確信をもてるようになったら、協働的ワークショップをひらいて合意での技術選定とかステップアップしていこう12分
演習13.4.3 権限委譲ポーカー(デリゲーションポーカー)
Management 3.0 というウェブサイトで印刷できる
https://management30.com/practice/delegation-poker/
↑多分、説明Youtube 3分半を見るとはやい
前の頁で出てきた、7つの権限委譲の段階がでてくる
全メンバーが、この案件については、どの委譲レベルでできるか示して、その委譲レベルのもとで会話してみる、ということらしい 20.5ふん
自信のある(技術)領域だとレベルが高くなる
これはゲームだけど、レベル決定に不満を持つことがあって、その不満の原因をはっきりできれば、いきなり実践で不満をもつよりいいね
やってないけどこのくらいで… 22分
223 アを出荷する力を持つのはチャ(人ではない)。トはそういうことができるようにチャを育てるのみ 23分
ソフトウェア
224 トとしては、全体の最小限のチャを設計して、他の部分はそれぞれをムに任せられたりできるといいよ 24.5ふん
(全体的な)設計判断を軽量な文書化するといいよ
技術的負債リストと返済計画をつくるといいよ 26分
チャをムで設計しよう チーム
224 大体の場合は、プログラミング自体は簡単な領域だよ 27分
難しいのは問題の理解と、解決のためにいろいろなシステムをどう連携させるか決めること
225 13.6 Lionheartプロジェクト(例題)は完遂した 28分
Lionheart プロジェクトでは 前払いのチャ設計を少なくしたらしい
大体の中規模プロジェクトでは20%と書いてあったね 29分
最後にメンテナンス ントを書いたよ 30分
引き継げるように、しっかりしたントを書いているのだ (じぶんも静画の最後でやった(そう指示を受けたので、上長の指示が正しかった))
年間1億円浮いた (MVP) 32分
226 これで第一部と第二部はおわり
次からはアクティビティ一覧が始まる 32.5分
銀の道具箱のプラクティスも使って、楽しく設計していきましょう 34.5分
ここまでの感想 (Design it)
いきなりアーキテクチャパターンなどを学ぶよりも、どういうシーンで使われるのか知れたことで、入りやすくなったと思う
今日の時間まとめ
30分で 220-226 の7ページ
ただし、 演習13.4.3 (1ページ) が 10分
つまり、 6ページに20分 (1ページ3.3分)
大団円とあって、結構書くことが多かった (23行)
(2行かくのに1分なので、 11分は書くのに使っている)
それを引けば、読むだけなら、 6ページ9分 (1ページ1.5分)
明日からは、(大団円な内容ではないので) 書く量が減って加速するかな？ (明日も計測する)
