アート・オブ・アジャイルデベロップメント読書会 9.6 インクリメンタルな設計とアーキテクチャ
===
###### tags: `アートオブアジャイルデベロップメント読書会`

[読書会インデックスページ](https://hackmd.io/qzr55OUxR_aKBNKZjRaxwA?view)

# 関連リンク

* [Discord開始位置](https://discord.com/channels/767540649418686486/774111081634332673/792558277094801420)
* [connpass募集ページ](https://agiledevs.connpass.com/event/193498/)
* ハッシュタグ: [#agile_devs](https://twitter.com/hashtag/agile_devs)

# 自己紹介

- ファシリ役
-
- 読み上げ役
-
- タイムキーパー

# 参加の仕方

- マイクはいつでもONにして、話に参加して結構です。
- テキストチャットでも、コメントやリアクションでどんどん参加してください！ラジオ担当が拾っていきます。
- 聞いているだけの方もOKです！

# ディスカッションをより豊かにするためのグランドルール

[アートオブアジャイル輪読会はじめの1歩 - Speaker Deck](https://speakerdeck.com/t2kob/atoobuaziyairulun-du-hui-hazimefalse1bu)

- 参加者は毎回任意
- 今回は不参加、次回は参加をするといった気軽な感じ
- 途中参加も断然OK! まずは聞くだけでも大丈夫です！
- フィードバックを恐れない
- マサカリは怖いと思いますが、アウトプットからのフィードバックを受け、学びを深めていきましょう
- アウトプット7割：インプット3割の気持ちで臨みましょう！
- 経験の有る無しは気にしない
- 自分はアジャイル非経験者だから……と気後れする必要はないです
- 堂々と意見や疑問を語りましょう
- ページ数と同時に、節のタイトルやキーワードを言って頂けるとスムーズです
- 電子書籍で読んでいるとページ数ではわからないため
- 話していない人が、率先してメモしましょう
- このHackMDはみんなのものです。どんどん書いていきましょう:+1: :+1: :+1: :tada:
- 気になる質問や同感するものには :+1: を末尾につけてください。

# タイムテーブル

| 時間 | 所要時間 | 内容 |備考 |
| -------- | -------- | -------- | -------- |
| 19:50- | - | 集合開始 | |
| 20:00-20:15 | 15分 | 当日の流れとグランドルールの共有 | |
| 20:15-20:25 | 10分 | 参加者アンケート | |
| 20:25-20:35 | 10分 | 感想記入&HackMDに書かれた皆さんの感想・気づき・疑問をもっと掘り下げたいものを、 :+1: 付けていく | |
| 20:35-21:35 | 60分 | 本の節ごとにディスカッション（ここでも適宜、HackMDに気づきとか書いていってもらっていいです） | |
|21:35-21:40 | 5分 | 次回開催日と読む範囲決めてクローズ | |

# 下に感想などを書いていって下さい。どんな些細なことでもOKです。

# 感想など

## 感想・気づき :+1:
### 9.6.1 どのように機能するのか
- > 抽象化を先送りすることで、ずっとシンプルで強力な設計を行うことができる:+1::+1:
- プログラマの性分ですぐに抽象化してしまいたくなるけど、XPではそうしないことで設計をよりよくすることができるというのは発見:+1:
- 将来発生する問題に対処するため前払いするよりも、今直面している問題を解決するという観点で設計を改良していくことなんだなと理解
- これをするためにはテストがないと無理だと思うので、TDDもセットで実施しないといけないんだなと思った:+1::+1::+1::+1:
- > 現在直面している問題だけを解決するようなシンプルな設計を作ろう
- > 1回目に、2回目に、3回目に・・・という話
- TDDの3点測量と呼ばれるものにかなり近そう
- FizzBuzzで「3」に対して「Fizz」を返す条件を `if(input == 3)` でベタ書き、「6」で少し抽象化し・・・と進めるやつ:+1:
- > 「2回目にその設計要素に取り組むときは、設計をもっと一般的にするように修正しよう」 - p.345
- さらに「3回目にその設計要素に取り組むときは、設計をさらに一般化しよう」と続くあたり、単にその時必要なものを段々"増やす"というアプローチではない、と見た方が良さそう
- 段々と"増やす”というよりは、段々と”広げる”、という感じ
- 一般化を段階的に行うのであって、一般化せず具体的なケースへの対応を段々と増やすわけではない感じ:+1:
- 一番最初にやらないというだけで、一般化・抽象化は必要:+1::+1:
- 「最初」で全て作ろうとしないだけで、一般化もいわゆる「設計」も、否定はしていないように見える（「アジャイルは設計しない」への反駁として）
- そもそも、ここで言う「最初」をそのままリリースまで持っていくことあるんだろうか/想定してるんだろうか？
- 段々と”広げる”あたりは、DDDのモデリング・設計プロセスにも通じそうに見える:+1:
- と思ったら、 p.346 で引かれてた
- > これを実現するには、一連のリファクタリングが必要になる。エヴァンスはこれをブレイクスルーと呼んでいる［Evans］（図9-2を参照）。
- >最初にインクリメンタルな設計のことを聞いたとき、私自身、とても懐疑的だったことを認めよう。
- 実際に経験・実践してみないと「インクリメンタルな設計」の良さには気づくのが難しそうだと思った:+1::+1::+1::+1::+1:
- TDDもライブコーディングやハンズオンをしてみて自分は良さを実感できたため
- インクリメンタルな設計を通じて設計が改善していく具体的な例を実際にみてみたいと感じた
- [Discord](https://discord.com/channels/767540649418686486/774111081634332673/792728423319470080)
- :memo: 体験談
- :memo: 軽量DDDをインクリメンタルに導入しました
- :memo: ここでいう「インクリメンタル」にあたるかはわからないけれど、最初に青写真的な設計図を描いてから実装・テストしつつガンガン設計も変えるのはよくやる
- クラス図だったり、もっとゆるくパッケージ図レベルだったり、あるいはユースケース図からプロトタイプだけ作ってみたり的な > 青写真
- :memo: 全面的に見直すのではなく、新しく作るAPIだけ、まずDDDでやってみる -> メリットを感じる -> みんなに共有 -> 徐々にDDDに寄せていく、という流れで行いました。
- :memo: 最近まさにペアプロを始めましたが、チームで知識レベルが揃って良かったという意見がチーム全員（4人）から出ました。
- 1人が強く言い出して、すんなり受け入れられました。運が良かったので参考にはならなそう。。

### 9.6.2　継続的な設計
- > インクリメンタルな設計では、まず具体的な1つの問題を解決するための設計要素を最初に作ってしまう。 (...) 顧客から追加の要求があると、 設計はインクリメンタルに進化していく。 - p.346
- 実際の「追加の要求」（＝顧客が「これやりたい」と実際に新たに持ってくる）を待たずとも、実践可能なようにも思える。
- 「〇〇ができる」「ただし、△△の時は、〇〇はできなくなる」という要求があったとして、「○○が〜」を一つの「要求」とみなし、「ただし〜」を「追加の要求」と見なして設計・開発するイメージ:+1:
- >通常は、徐々に小さな変更をしながら、数サイクルかけて既存の設計でコードを実装していく。すると、どこからか新しい設計アプローチのためのアイデアが生まれる。
- ストーリーが1つ1つ具体的で細かく設定するのが必要だと思った
- 変更が大きいものをこの方針でやると、結合度が高い設計になったり、より良い設計に気づくタイミングが少なくなってしまうと思った
- 抽象化すべき派にいつも未来を予想できているつもりなだけど伝えてます

### 9.6.3 インクリメンタルにメソッドを設計する
- >メソッドのリファクタリングは数分ごとに発生する。ブレイクスルーは１時間につき数回起こり、実装が完了するまでには10分かそれ以上かかるだろう。
- それぞれ具体的に目安の時間が書いてあるので実践してみる時はこの時間を参考に振り返るとうまく実践できているか確認する指標の1つになるのではと思った:+1:

### 9.6.4 インクリメンタルにクラスを設計する
- ペアプロしていて、課題を見つけたらメモするのはいいな:+1::+1::+1:
- :memo: モデリング会では、紫付箋においておくのをしたら、すごく効果があった
- hotspotというらしい
- 10分間ルールの意識は大事。意識し続けないと、つい議論が白熱して何も進まないとかありそう。:+1::+1::+1::+1:9.6.4
- [Discord](https://discord.com/channels/767540649418686486/774111081634332673/792731434799988808)
- :memo: Talk is cheap, show your code! by リーナス
- :memo: ペアプロの話を止めて、この話ができてるのがまさに成功例な気がw
- :memo: 議論大好きな人間が二人そろうと、2hとか平気でやるのでアレ（片棒）
- :memo: 時間ルールだと熱く語っている人を邪険にしたことにならなくていいですね。（あなたを無視ではなくルールなんでって言える）
- :memo: 最近は、現場でも「論よりコード」を意識して取り入れてる :+1:
- 論よりコード
- :memo: 「ちょっとしたコード」で済まない（構造に関わる内容とか）の場合、実装コード書かずにIFだけで書いてみるのも効果的感 :+1:
- :memo: まさに「方針を考える」の段階で、IFだけで書くのが強力（という体感）
- >すべてのリファクタリングをやる時間よりも、リファクタリングをするチャンスはいつでもたっぷりある。TODOやリファクタリングカードは、それほど価値があるわけではないのにチームに過度のストレスを与えることになる。
- わかりみ。リファクタリングを大きく構えすぎて(例:全面的にリファクタリングする!)、時間やコストかけられないから結局リファクタリングしないという事例(?)を多く聞く印象があります。リファクタリングは息を吸うようにするくらいで考えていれば気軽にできると思います。プログラミングの工程で息を吸うようにTDD、リファクタリングを含めてしまうと、TDDやリファクタリングに対してわざわざ顧客やマネージャーと交渉する必要もないかなという印象。:+1::+1::+1::+1:
- [Discord](https://discord.com/channels/767540649418686486/774111081634332673/792733988669095936)
### 9.6.5 インクリメンタルにアーキテクチャを設計する
- > まずは設計の一部にだけ新しいパターンを試してみることから始めよう。しばらく（1週間か2週間）そのままにして、実際のところその変更がうまくいったのかどうか確認しよう。それがうまくいくことを確かめたら、システムの残りの部分を新しい構造と整合が取れるようにしていこう。日々の作業で手を入れたクラスをリファクタリングしよう。 - p.348
- 実際、新機能作る時に「こうすれば良い感じになるのでは？」というのを部分的に導入したこと何度かある（粒度はまちまちだけど）:+1::+1:
- そこで実際に好感触を得た後で、他の部分の改修や新規実装でその仕組（≠コード）を流用したり
- 実際、全体にエイヤで一度に適用するのは現実的ではないので、現実的にも「新しい解法」の導入はこうならざるを得ないと思う
- この意味で、「全体の仕組みが統一されている」というのは、必ずしも”常に”実現されていなくても良いんじゃないか的な感覚:+1:
- "常に"にこだわると、一度にエイヤ以外の手段がとりにくそう
- 最終的には整合する/させるのは前提なのだろうと思いつつ
- > 新しい開発をちょっと中断してリファクタリングをすることもできるが、これだと顧客の権利を奪うことになってしまう。技術的卓越と実現する価値のバランスを取ろう。 - p.348
- > アジャイル開発は、個人的な成功、技術的な成功、そして組織的な成功を同時に達成することを重視している。 - p.6
- ここの言及は、まさに三者のバランスを取りに行くよう促している内容に見える

### 9.6.6 リスク駆動アーキテクチャ
- > 　私はこれまで設計することに着目してきたが、将来の問題について考えるのはいいことだ。ただし、まだ スケジュールされていないストーリーに対する解決策を実装してはいけない。 - p.349
- 「将来のことはわからない」からの「だから考慮しない」的な言説への個人的モヤモヤを言語化してくた感 :+1:
- 未来がわからないからといって、それを「実装しない」と「考えない」はイコールではないよなあ、という感覚
- > こうした取り組みは既存の設計を改善することだけに限定しよう。顧客がローカライズされたフォーマットを求めるまで、実際には実装してはいけない。 - p.349
- 未来を考慮して、それによって破壊的な影響がでない、あるいは出にくいような形に設計してはおくものの、それおまさにサポートする内容を現に”実装”まではしないという呼吸、しっくりくる。
- 「実装」はしないが、それを考慮した（リスクを無くす、あるいは軽減できるような）設計にリファクタリングしておくというのも、違和感は無い
- ローカライズしようと思えばできる形にはしておく（その時には、当然新たに実装する必要が生じる）が、実際にローカライズ機構を実装したりローカライズ定義まではしない、という感じ。

### 9.6.7 コーディングだけじゃない
- > 予測による設計はXPではほとんど役に立たないが、それでも使い道はある。新しい機能を追加しているとき、TDDでどのテストを次に書くべきかを決定する助けとして使おう。もっと大きなスケールでリスクを検討して、リスク駆動 アーキテクチャを実施するために、予測による設計を使おう。(...)自分でやってみよう。そして、あなたにとって最もうまくいく予測による設計とふりかえりによる設計のバランスを見つけよう。 - p.351
- 「予測するな」ではなく「予測は（文脈問わず）役に立たない」でもなく、「上手く使おう」ぐらいに見える
- up-front一辺倒でもbottom-up一辺倒でもない塩梅として、順当なまとめに見える

### 9.6.10 使用上の注意
- > 継続的に毎日改善するというコミットメントなしに、インクリメンタルな設計を使おうとしては行けない
- これが「普通」の感覚の開発と大きく前提の隔たりがありそう。これ抜きにして「シンプルに」と言って先送りにして、対応するのが数週間、数ヶ月後とかがあるあるでは:+1::+1:
- そうではなく、一旦後回しにしたやつを数時間、数日で回収するぐらいの気持ちなんだろう
- 重たい変更を如何に後回しせずに行えるか。
- > 　継続的な改善が難しくなるということは、インクリメンタルな設計が難しくなるということだ。(...)最後に、リファクタリングにおける技術的な障害よりも組織的な障害を抱えている組織もある。(...)こうした状 況では、インクリメンタルな設計はふさわしくないかもしれない。 - p.353
- 「インクリメンタルな設計」というアプローチの限界にもちゃんと言及してる感じ
- 万能さを嘯くでもない感じで良い

### 9.6.11 代替案
- >どうも気が気でないのであれば、前払いの設計と組み合わせよう
- 現実的に可能なラインはこれかなあ:+1:
- ここを試してみて徐々にインクリメンタルを増やす
- アーキテクチャを1回決めた後には変化させられないくらいの現状からは脱却できる

--------------------------------------

## 疑問・参加者に聞いてみたいこと
### 9.6.1 どのように機能するのか
- > 現在直面している問題だけを解決するようなシンプルな設計を作ろう
- これが具体的にどういうことなのか、具体例を考えてみたい :+1::+1::+1::+1:
- 9.4.4のリファクタリングの事例で考えてみてもいいかも
- :memo: クリーンアーキテクチャは複雑にしすぎちゃういい例かも
- [Discord](https://discord.com/channels/767540649418686486/774111081634332673/792715400517386280)
- :memo: たとえば、テキストメッセージを送信する、ということをメールだったりSlackといったインフラの部分や、テキストメールじゃなくてHTMLも対応しよう、とあれこれ最初に頑張っちゃう系の話ですかね。
- :memo: Clean Architectureを頑張って適用したあと、明らかに規模に対して潔癖になりすぎたと感じた事ならあります。メンバー馴染み深いMVCで良かった。
- 前払いの設計で痛い目をみた事例について、参加者の経験を聞いてみたい:+1::+1::+1:
- [Discord](https://discord.com/channels/767540649418686486/774111081634332673/792718083533963264)
- :memo: ストーリーベースですすめると軌道かえやすく、細かなパーツ（機能）量産を並列で行うと辛そうなイメージです。細かなパーツを並列で開発できるとの判断が前払い設計かなと
- :memo: いきなり横展開して進めちゃうのは、毎回抽象化するのに反している
- :memo: 特定の入出力形式を強く前提に置きすぎて、後から生じた問題を吸収するのが大変になった（なってる）こともあったなー（今思い出した）
- csv前提、excel前提とか
- :memo: 前払いの設計、というよりも前払いの実装が (ただしフロントから呼ばれていない) 、新しい機能を実装するにあたって余分な工数を生んだということを聞いたことがあります
- YAGNI
- :memo: シンプルにいきましょう。と伝えたら最もシンプルだったという理由のコピペ。。。（インクリメンタルにリファクタの思想とペアですすめることができなかった）
- :memo: シンプルとは過度な単純化を意味しているわけではない。クラスやメソッドの数を削減するという名目で、愚かな設計判断をしてはいけない。 シンプルな設計とはきれいでエレガントなものであり、ほとんど何も考えずに間に合わせで作るようなものではない。 - p.339
- 前払いの設計を一切「していない人」はどれくらいいるのだろう？(居るの？):+1:

### 9.6.5 インクリメンタルにアーキテクチャを設計する
- > この繰り返し発生するパターンは、アプリケーションアーキテクチャを具体化したものだ。これらは一貫性のあるコードをもたらすが、それらはある意味で重複でもあり、アーキテクチャに対する変更をさらに難しくしている。
- ここでいう"重複"とはどのようなことを指しているのだろう？:+1:
- 特定のアーキテクチャを採用した時に書かなきゃいけないボイラープレートコードみたいなもの？
- [Discord](https://discord.com/channels/767540649418686486/774111081634332673/792721977931726850)
- :memo: 似たような構造のコードを何回も書くことになる、的な意味かなと解釈
- :memo: Four†で言うところのデザインパターンではない。そうではなく、コードベースに特有の標準的な慣習だ。 - p.348
- :memo: ここで言う「慣習」に従って書かなくてはならないものを指して「重複」と言っているのかな、的な / 「慣習」に従うということは、その「慣習」を前提としている何かに暗黙的に依存しているということであり、その”前提としている何か”がアーキテクチャである場合、その意味での重複は「アーキテクチャに対する変更をさらに難しく」する、的な
- :memo: ORMとかのお作法とかはすごく該当しそう
- :memo: 自作のFW感
- :memo: 自作でなくても、RailsならCoCという慣習に縛られて、それに基づいた似通った構造（命名やディレクトリ構造）が「重複」したりとかかな
- :memo: 「幸運なことに、インクリメンタルにアーキテクチャを設計することも可能だ。」ってオレオレFWとどう違うのかは気になりました - p.348
- TODOやリファクタチケットを切らないとなると、大幅な設計変更が必要な時にどうすればいいのか気になります。別にチケットあっても着手されないんですけど、インクリメンタルだとどうしたらいい？
### 9.6.6 リスク駆動アーキテクチャ
- 結局リスク駆動アーキテクチャってどういうこと？(定義がビシッと書いてないような) :+1:
- `Risk Driven Architecture` で検索したところ [Risk-Driven Approach](https://www.amazon.co.jp/Just-Enough-Software-Architecture-Risk-Driven/dp/1439812349) を表題に含む本が見つかったが、参考文献には無い
- ↑の本(at 2010)の方が、この本（AOAD at 2009）より後だった……
- （著者が個人的に話を聞いていた、という可能性も無くはないが、現状は妄想）
- http://www.methodsandtools.com/archive/agilesoftwarearchitecture.php あたりを見ると、それほど遠くはないような気もする
- [Discord](https://discord.com/channels/767540649418686486/774111081634332673/792724885855535104)
- :memo: 将来のリスクとして何が考えられ、それをどう吸収するか、あるいはしないのかを考えて、設計を検討するみたいな印象
- :memo: 変更される可能性、変更するとしたときのコスト、ですかね
- :memo: 将来のリスクを減らすからやるもの。個人のこだわりではない。
- :memo: YAGNIやKISSの名のもとに将来の話が切り捨てられがちな印象が有ったので、このあたりは個人的に腹落ち感が強いです :+1:
- :memo: 個人的に、YAGNIやKISSは視点を増やして再検証するためのツールで、結論を出すツールじゃないという感覚

### 9.6.7　コーディングだけじゃない
- P.351 CRCカード、使ったことある人いますか？:+1:
- [Discord](https://discord.com/channels/767540649418686486/774111081634332673/792727565672120330)

## ミニエチュードの質問
* ミニエチュードは、このプラクティスに対して気づきを得るための質問です
* 詳細はP76ページを参照してください
* 以下の質問に、回答を継ぎ足していってください

### (このプラクティスを使ったことがなければ)
- 何が簡単だと思ったか、何が難しいと思ったか、何が馬鹿げているように思ったか？
- これまで経験したものとどう違うか？
- アーキテクチャはなるべく早く決めるものであるという固定観念があった
- 書かれているとおりに正確にやるには、どういう条件が当てはまっている必要があるか？
- TDDなどを実践して、リファクタリングをするのにリスクが少ない状態が必要だと感じた

### (このプラクティスを使っているなら)
- 自分がやっているプラクティスは、本書に書かれているもの突どんな点が違っているか？(気づいたことだけでいい、理由はいらない)
- もし書かれているとおりに従うと、何が起こると思うか？
- このプラクティスについて新しい洞察を得るために、お試しでやり方をどこか変えてみることはできそうか？(プラクティスが不適切だということを多足噛めるために、お試しでやってみるのは良いことだ)