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

https://gyazo.com/c683784d06cbd3dbf75d03f7f6a52ed3

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

参加者 ：

イベント：

Zoom ：

対象 ：3章　漸進的な変更を支える技術

20:30-20:40 10 min 近況

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

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

はじめに

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

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

近況

3章　漸進的な変更を支える技術

pp.33-36

p35 そうしてデプロイされた実行中のサービスインスタンス間の経路から構成されている

デプロイメントパイプラインがサービスをデプロイすると、サービスはサービスディスカバリツールを使って自身を登録する。

有名なのはetcdっぽい、Kubernetesでも使われてるみたい

クライアントサイドとサーバーサイドの方式があるみたい

他のサービスから呼び出されなくなったことを検出する閾値も、適応度関数の１つになる？

DBリファクタリングでも、新旧共存させておいて、トリガーでデータを流し込むという方法を書いていた。DBへのアクセスがなくなる時に、旧テーブルを捨てると書いていた。その検出はどうするんだろう。ログとかなのかな。

10shi10ma.icon

進化するための機械的能力は、進化的アーキテクチャの重要な要素の 1 つだ。(Page 35).

機械的能力ってなんだ？

マイクロサービスでの例の紹介が主だったので、そこまで感想無し

このあたり詳しくないからかも

新しいサービスをデプロイする際、チームは呼び出し元のサービスに対して直ち に新しいサービスへアップグレードすることを強制したくはないものだ。(Page 36).

サービス利用側がタイミングを選べるのは漸進的な変更において大事そう

3.1 構成要素 - 3.1.1 テスト可能 pp.37-40

tfujita.icon

P37 よく略図を作成することによって行われ、様々な度合いの儀式を伴う

作った気になってしまうところもあったり、作ったことによって難しく考えすぎてしまうこともあるなあ。

図３ー4みたいな書き方も今度やってみようかな。進化中のプロセスのスナップショットかあ。

p37 コンピュータ上を１ビットでも変更していないにもかかわらず、世界全体は動き続けていたのだ

Oh, Windows...

勝手に更新しないで欲しいww

p38 初期の「未知の未知」

makopi23.icon

P.40 「何らかのアーキテクチャ特性を評価するのに役立つツールであれば、それは適応度関数とみなせる。」

やはり適応度関数という名前がしっくりこないな

処理方式設計書でアーキテクチャのお作法を守りましょうというのはやるが、アーキテクチャの違反はレビューなどでチェックするくらいだった。どうやるんだろう。

MVCモデルのViewからModelアクセスしたらだめとかをチェックしてくれるのあると面白いね。

フロントエンドは、このパッケージ読み込んではいけないというのをLintでやろうとして、既存では存在しなかったけど、ルールを作れるので自分でできそうだった。

実際は、そこまでやるか？ということで放置となった。

静的解析ルールを自分で作るのは骨が折れるので、間引いて適用するというのは多かったなあ。その静的解析ルールの仕様理解も必要になるし。

チームとしてワーキングアグリーメントとして合意、スプリントレビューの前提条件の完成の定義にルールを作るなど。人間の力で頑張るというのをやったりはするかも。

P.40 「アーキテクチャの違反を検出するためにはユニットテストがお薦め」と書いてあるけど、そんなテスト書いたことないなぁ。どう書くのだろうか。。

10shi10ma.icon

一般的に売られているアーキテクトが利用するツールは2次元だけど、我々が取り組んでいるものは4次元

合理的なアーキ テクチャ計画は、進化的変更を含める必要があるのだ。(Page 37).

確かに計画たてるときに周囲の変化は入れてないな

インセプションデッキでも初期アーキテクチャを決めてその後見直していきましょうということが多いと思う。

アーキテクチャは、実際に作られ運用されるようになるまでは抽象にすぎない。(Page 38).

名言っぽい

ソフトウェアアーキテクチャのなかで無視されていることの多い「～性」が、テス ト可能性だ。(Page 39).

一見テストが困難な特性に見えても、テストして自動化することは可能

意外に自動テストできるものって多い

JSだとLinterで循環参照チェックするやつとかもあるよ

画面のテストはやってる？

DOMの存在チェックをしてたり、ピクセル単位でのチェックをしてるところもあるかも、あとは手動かなあ。

3.1.2 デプロイメントパイプライン pp.41-46

tfujita.icon

p41 加えて、GoCDなどのオープンソースのツールは、

知らないツールだ、気になるなあ。しかし、使い始めるのが大変なイメージ。。

p44 この調整問題の解決には、デプロイメントパイプラインのファンアウト操作がよく使われる。

ファンアウト聞いたことなかったなあ。

p45 機能トグルを使用するというものがある。

聞こえはいいが、ViewがIf文だらけになるだろうか・・・

機能トグルやってる

公開してるけど、利用者はアクセスする口を知らない。

makopi23.icon

P.42 デプロイメントパイプラインで適応度関数を実行する話

Azure Pipeline使ってるけど、テストカバレージと循環的複雑度は自動で取得してるなぁ

ソースコードの行数とか

スプリトレビュー前にここの数値が違反してないことを確認しいる

あとは、静的解析でひっかかった件数とか、

10shi10ma.icon

デプロイメントパイプラインとか機能トグルは結構身近なのでイメージしやすかった

Jenkinsでやってる、テストと静的解析をやってる。

引っかかった件数が適応度関数になるのかなあ

DBでオンオフするパターンと、ユーザーがオンオフできるパターンで機能トグルを使ってるなあ

3.1.3 適応度関数の分類を組み合わせる pp.46-48

今日のふりかえり

役に立つ(?)リンク

次回

日時： 2020/10/7 (水) 20:30 - 22:00

対象： 3.1.3 適応度関数の分類を組み合わせる - ３章の終わりまで

ページ：46 - 58

役割分担

33-46, 13