進化的アーキテクチャ - 読書会 第2回

https://gyazo.com/c683784d06cbd3dbf75d03f7f6a52ed3

日時 ：2020/9/2(水) 20:30 - 22:00

イベント：

Zoom ：

対象 ：２章　適応度関数

20:30-20:40 10 min 近況

20:40-21:50 読書会わいわい（司会のかた自由にデザインしてくださいね）

21:50-22:00 ふりかえり

はじめに

気になったコメントには、顔アイコン(ショートカット: Ctrl + i)で教えてください。

できる限り自分のログは自分で残して、みんなでログを作り上げましょう。

近況

名古屋から初参加の川路です。 AWSと中心としたソリューション開発が多めな人です。

ノリックさん：初参加！3ヶ月前に子ども産まれた！

２章　適応度関数

pp.19 ~ 21

tfujita.icon

p20 個別の適応度関数とは異なり、システム全体の適応度関数を「評価」することは決してできない。

適応度関数には、個別とシステム全体が存在する。

システムは決して部分の総和ではない。システムは部分の相互作用の成果だ。

足し算だけで考えてちゃダメってことかあ。わかってても見失いがちになっちゃうなあ。部分の相互作用ええ言葉やなあ。

ソフトウェアにおいて適応度関数がチェックするのは、開発者がアーキテクチャ上の 重要な特性を維持できているかだ。 (Page 19).

ここで出てくるようなソフトウェアは長年運用されるイメージなので、アーキテクトや開発メンバーも変わっていきそう & 重要な特性も変化するはず。その時重要な特性をどのように明文化するイメージなんだろう。

特性はトレードオフがどうしてもあるので、システム全体の適応度関数が約に立つ。

ステークホルダーはおしなべて自分の関 心事が最も重要だと考えているからだ。(Page 20).

ステークホルダーだけじゃなくて、ある程度の規模になると開発メンバーにとっても当てはまりそう。

ノリックさん：誰にとっても自分の関心ごとが大事だよねえ

川路:普段行っているScrumに通ずるものがあるなと

ステークホルダーはおしなべて自分の関心事が最も重要だ (P20)

この出来ないことを認めて進めることが重要と感じた

システム全体の適応度関数を「評価」することは決して出来ない (P19)

言い切ってくれる存在は、心を軽くしてくれるなあ

定量的な評価や定性的な評価も含まれてそうだなあ

システム全体の適応度関数ってどんなのだろう

個々の項目のリストなのか、そうではないのか？

2.1 適応度関数とは ~ 2.2.1 アトミック vs ホリスティック pp.21 ~ 24

適用度関数って単語、エンジニアだとなにか数式とかinputとoutputがあるようなものをイメージしちゃうと思った。

ノリックさん：メトリクスだと足りない？ようにも感じるかもなあ。合否があるように感じるし。でもメトリクスでもいいように感じる

メトリクスは定量化のイメージが強いね

アーキテクチャの適応度に影響を与える可能性のあ る変更についての議論を楽しむこともできる。

(Page 23).

議論の土台になるのがよい点だなーと思えてきた

tfujita.icon

p21 数学的に言えば、関数とは許された入力値の集合から入力をとり、許された出力値の集合内からある出力を生成するものだ

やっと適応度関数の定義方法？について具体的な記述があったように感じる。

個別の適応度関数って、入力値がxxだったら知らせるみたいなものなのかな？？

p22 すべての適応度関数を自動化できるプロジェクトばかりでは無いからだ。

これも川路さんを癒せるワードかもしれない！

川路 「vs」って表現はミスリードな気がしました。（互いに対立はしてなさそう）

アトミック＝ユニットテスト可能, ホリスティック＝シナリオテスト(BDD)？

適応度関数は必ずしも単一のスクリプトとして実行できないし、「アーキテクチャの現在の総合的な適応度は42です」と言ったりすることはできないものだ。

2.2.2 トリガー式 vs 継続的 ~ 2.2.7 ドメイン特化なもの pp.25 ~ 28

tfujita.icon

P25 したがって、開発者は実際のすべてのトランザクションが実行されている本番環境のトランザクションを模倣する適応度関数を構築する

本番と同じようなテスト環境を用意して継続的にチェックするってことなのかな？？

わかるような、わからないような。実現方法が特にイメージしづらいなあ。。

P.25 人気を得ている他のテスト手法に、モニタリング駆動開発

何すかそれは？！？！監視のことかあ。こんな言葉があるんだなあ

10shi10ma.icon

トリガーと継続的の話

継続的の部分が結構理解し辛い。CIとかで継続的に評価する話か？と思ったけど違うっぽくて、実際に稼働してるシステムでの検証的な話になった

いくつかの例を見て、なるほど。くらいの感想しか持てなかった

MDD: モニタリングちゃんとやって、そこからソフトウェア改善していこうぜ。って理解しました

akinasu.icon

P.26 法的要件

メトリクス等の既存の概念より大きな枠組みを一つの考え方で捉えなおすために「適応度関数」という言葉にしているのかな？

本番環境での監視を使って、技術的及びビジネス的な健康状態を評価する。 (P25)

これまでやってはいたものの類似環境を用意することを頑張りすぎていて本来は本番環境から評価に必要な値をもっと集めることに注力すればよかったかもしれないと反省。でもリリース前にわからないじゃん。というジレンマ

アップグレード中断テストをもっと詳細にしりたいなと

ノリックさん：原文も気になるなあ、中断て言葉があってるのかな？？

ビジネス価値への監視はあまりできてないかなあ

2.3 早い段階で適応度関数を特定する ~ 2.4 適応度関数を見直す pp.28 ~ 31

適応度関数を早い段階で特定しなければ、チームは最終的にこ れらの責務をコードベース全体へ分散させてしまうことになる。その結果、変更を理 解するには幅広い影響分析が必要となり、全体的な変更コストを跳ね上げることになる

(Page 28).

早い段階で適応度関数を特定しよう。

適応度関数のカテゴリは、技術や設計選択に重要なのか、関係あるだけなのか、関係ないのかを意識するの大事なので良さそう。設計初期は、関係ないところもこだわって、無駄に時間かかることもあるし。設計に重要なところにまずは注力したい。

最初に決めたことが誤っているときのダメージが大きいため、割り切って第一弾設計を捨てることが多い。（捨てやすく軽めでスタート切る）

関連性のないもの (Page.29)

ここを意識して完璧主義と戦っていかねばと決意

すくなくとも１年に１回は適応度関数を見直そう。 (Page.30)

必要だが、この１年はいい加減さを感じるがやらないよりいいですね。（年１の避難訓練なイメージかな）

tfujita.icon

p.29 セットベース開発

とは・・・？？

並列的に複数のことを試すこと？？

p30 適応度関数レビュー

ビジネス能力も点検するというのが興味深い

kazweda.icon

アーキテクチャ上の側面を検証するために「スパイク」の実施に時間と労力をかけることに価値がある。(p29下)

取り組み方、段取りの仕方が時間かかりそうだなあ

今日のふりかえり

外松さんが見つけてくれたMDDの記事、阿部さんは以前愛媛のアジャイルのイベントに参加されたことがあります。

斎藤: みんなのモヤモヤが聞けて嬉しかったです。読書会の進め方が効率的で良いなぁと思いました。

nrhide：やはり、様々な見解がでて、すごく参考になりますね

役に立つ(?)リンク

1グループ3〜5人のエクササイズ。全体で4から10グループが望ましい。

モデレータは時間の管理やカタの割当、あるいはランダムにカタを選ぶ。

次回

日時： 2020/9/16(水) 20:30 - 22:00

対象： ３章

ページ：

役割分担

19 - 32, 13