アート・オブ・アジャイルデベロップメント読書会 9.5 シンプルな設計
===
###### tags: `アートオブアジャイルデベロップメント読書会`

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

2021/01/10(日) 20:00-22:00 範囲: 9.5 シンプルな設計
Hack.md → https://hackmd.io/IWmiTqWCS4OMt6RNKtFm-A
Miro → https://miro.com/app/board/o9J_khBgWKE=/

2021/1/13 21:00〜 LT会＋懇親会準備会議します！

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

# Discord開始位置

* 2020/12/10 : [connpass募集ページ](https://agiledevs.connpass.com/event/200489/), [discord](https://discord.com/channels/767540649418686486/774111081634332673/797619474202099762)
* ハッシュタグ: [#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:

## 目安の時間

## 感想・気づき
- > XPの連中も道具箱の中にパターンを持っている。彼らは必要なときにパターンに対してリファクタリングをする。 - p.338 :+1::+1:
- "パターンに対してリファクタリングをする"というのが、正確にはどういうことを意味しているのか気になった
- 原文では *The XP guys have patterns in their toolbox, it’s just that they refactor to the patterns once they need the flexibility.*
- *patterns in their toolbox* からの *they refactor to the patterns* なので、「道具箱の中のパターン」に対してリファクタリングをしかける、という感じかしら
- パターンの内容をリファクタリングするということなのか、道具箱に入れるパターンを取捨選択する（≒使うパターンを選ぶ）のを指して、「リファクタリング」と呼んでいるのか
- 両方かしら
- 「リファクタリング」の書籍の中では、コードスメル(コードの不吉な匂い)を定義し、それに対してリファクタしようという話なので、それを指すかもしれません
- 原文では *they need the flexibility* と、「必要な」の対象を明示している。なんで日本語訳では、この部分を削ったんだろう……
- > シンプルとは過度な単純化を意味しているわけではない。クラスやメソッドの数を削減するという名目で、愚かな設計判断をしてはいけない。 - p.339 :+1::+1::+1::+1:
- Kent Beckも、XP本の方でまさにこのあたりを（より詳細な書き方で）戒めている
- > もっともシンプルな設計はクラスの数が最も少ない設計のことを言うのだろうか。しかしこれだと、オブジェクトが大きくなりすぎて、効果的ではない。ではもっともシンプルな設計は、メソッドの数が最も少ない設計なのだろうか。これだと、メソッドが大きくなったり、重複が起ったりする。もっともシンプルな設計はコードの行数がもっとも少ない設計なのか。これだと、圧縮のための圧縮が起り、コミュニケーションが損なわれてしまう。 - Kent Beck(2000)『XP エクストリーム・プログラミング入門』 p.111
- が、「シンプルにしよう」と言いながら、クラスを作ること自体が拒否される現場もままあったなあ（遠い目）
- 「そのクラスは不要だよね」という議論によってではなく、クラスが増えることそれ自体がNGかのように・・・

### ケント・ベックの考えるシンプルさ - p.338
- ここで"ケント・ベックはシンプルな設計のことを〜"と紹介しているけれど、引用元は `10章/概略/シンプルな設計` ではなくて `17章/設計戦略/何がもっともシンプルか` の方っぽい
- 「書いていること全然違うじゃん」と、しばらく混乱した・・・
- [Martin Fowlerもそう](https://martinfowler.com/bliki/BeckDesignRules.html) だけど、引用する時はどこから引っ張ってきたのか、ちゃんと（書名だけでなく、章とかページとか）書いて欲しい・・・
- クリーンアジャイルで「シンプルとは、直接的ということだ」とあった。これは個人的には結構面白い発見

### 9.5.1　どうせ要らないって（YAGNI: You Aren't Gonna Need It）
- > この簡潔なXPのことわざは、シンプルな設計の重要な側面をまとめたものだ。 - p.339
- 「えっ、YAGNIってXP由来だったんだ」と思ってKent BeckのXP本見たら、索引にYAGNIが無くて、アレッとなった
- [英語版のwikipedia](https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it#cite_note-XPi-1) を見ると、『Extreme Programming Installed』（和書『XPエクストリーム・プログラミング導入編』）への参照があるが、そちらでも「XPのもっとも有名かつ賛否両論を呼ぶスローガン」と紹介されていて、少なくともこの『導入編』が出典というわけでもなさそう
- > YAGNI―You Aren't Gonna Need It（それは必要にならない）という、XPのもっとも有名かつ賛否両論を呼ぶスローガン - Ron Jeffries(2001)『XPエクストリーム・プログラミング導入編』p.240
- [c2wiki](https://wiki.c2.com/?YouArentGonnaNeedIt) でも [extremeprogramming.org](http://www.extremeprogramming.org/rules/early.html) でも、「XPのことば」として紹介されている
- 出典が良くわからないなと思いつつ、Margin Fowlerいわく、 ["C3プロジェクトでのケント・ベックとチェット・ヘンドリクソンの初期の会話"](https://martinfowler.com/bliki/Yagni.html#footnote-origin) らしい
- 「この話の出典あるいは出どころは？」というのも気になりつつ（口頭で直接聞いたのであれば、そう書いておいて欲しい）

- > 推測に基づいてコーディングするのを避けよう。設計に何かを追加しようとしているときにはいつも、それは今まさに実現しようとしているストーリーや機能をサポートするものか考えてみよう。もしそうでなければ、それは要らない。設計は変化するだろう。顧客の気も変わるだろう。
- すごくよくわかります。将来使うかも、と今は要らないデータフィールドを持たせていることで、それが別の要件を追加するときの足かせになることが過去ありました。設計するときは、今それが必要なのか、今実現するにあたって必要最低限になっているか、を常に考えるようにしています。:+1::+1::+1::+1::+1:
- テックリードに「ALTER TABLEしたくないから」という理由で「将来こうしたいから」「いつか使うと思うから」というテーブルやカラムを追加させられたシステムがその後どうなったか…

- YAGNIについて「予測しない」「推測しない」という言葉が使われることにずっとモヤモヤしていたけど、ここで言う「予測」「推測」が、「要求に由来しない」ということであれば、ちょっと納得感:+1::+1::+1:
- > ガンマ：あるいは新しい要件が出てきたときも同じことだ。私は要件駆動の柔軟性が本当に好きなんだ。 - p.338
- こうした「要件駆動の柔軟性」ではなく、プログラマだけで完結した（ステークホルダーとの相談などを含まない）当て推量を戒める意図であれば、納得
- そのような意図であるならば、未来のことを考え語る事自体を妨げるものではないと考えても、外したものではないのでは
- さりとて、「9.6.6 リスク駆動アーキテクチャ」のお話も踏まえてYAGNIは考えたい:+1::+1::+1::+1:
- 未来に思いを馳せる場面は、多少なりとも必要だろうと思う:+1:
- YAGNIやKISSの名のもとに、それらが排斥されるのはマズイという感覚が強い:+1:
- リスク駆動アーキテクチャの話を読書会でした時にも話題に出ましたが、リスク駆動ありきでのYAGNI、という話がありましたね
- 大半のリスクは回避策があって、本当に回避できないものや致命的なものだけに選定しないと結局YAGNI違反しそうな気がします
- 「そもそも、完全な予測はできないし、予測しても外れる」というのが前提にあるように思う。:+1::+1::+1:

### 9.5.2　一度、ただ一度だけ（Once and Only Once）
- > すべてのコンセプトを一度で（ただ一度だけで）表現しよう。...すべてのコンセプトにちゃんと居場所があるか確認しよう。
- 一見似ているようで違う概念(コンセプト)を共通化することを避けるためにも、この文言はチームで共有したい。
- 「Efective Kotlin」で、「知識を重複させない」というフレーズがあり、個人的にはこちらも好みです :+1::+1:
- > 基本データ型を使う方がシンプルに見えるかもしれない。結局、1つもクラスを使わないのだからね。でも 実際には、設計をもっと複雑にしてしまう。コードにはコンセプトの居場所がない。 - p.340 :+1::+1::+1::+1::+1::+1:
- [discord](https://discord.com/channels/767540649418686486/774111081634332673/797803862169878538)
- p.339「シンプルとは過度な単純化を意味しているわけではない」のアレ

### 9.5.3 自己ドキュメント化コード
- > シンプルさは見る人次第だ。あなたが設計をシンプルだと思うかどうかは、それほど重要ではない。 - p.340
- EvansのDDD本にあった一節を連想した
- > これは素人にはわかりにくいが、エキスパートにとっては、ビジネスとの関連がはるかに深いものだった。 - 『エリック・エヴァンスのドメイン駆動設計』 3部 より深い洞察へ向かうリファクタリング/深いモデル
- その「シンプルさ」は、誰から見た、どのような意味での「シンプルさ」なのか、という問いとして
- 「誰に力を与えるデザインなのか？」という言葉も思い出した（出典失念・・・）
- [『誰のためのデザイン？』](https://www.amazon.co.jp/dp/4788514346) だったかしら
- > この問題を避けるために、言語やチームに共通のイディオムやパターンを使おう。新しいアイデアを導入しても大丈夫だが、まずそれらをチームの他のメンバーに最初に説明しよう。変数、メソッド、クラス、その他の構成要素の意図が明確に反映された名前を使っているのか確かめよう。 - p.340
- RESTで言うところの「自己記述」みたいな感じかなと思ったら、だいぶ違った
- 『リーダブルコード』的なやりくちというか、観点からの說明っぽい
- 書いている内容自体は納得
- > 何かを説明するためにコメントを使う前に、コメントを読まずにコードの意図を表現する方法がないか :+1::+1:
- [discord](https://discord.com/channels/767540649418686486/774111081634332673/797805684627996672)
- これめっちゃ大事。みんなドキュメントなんて書きたくないのだから…
- t_wadaさんのこれを思い出しました:+1:
https://twitter.com/t_wada/status/904916106153828352

    コードには How
    テストコードには What
    コミットログには Why
    コードコメントには Why not

### 9.5.4　サードパーティ製コンポーネントを分離する
- > 　この問題を避けるために、自分の管理下にあるインターフェイスを通して、サードパーティ製コンポーネ ントにアクセスしよう。 - p.341
- やることも有るし、サボることも有るかな感
- 中核部分は割とキッチリやるけど、Web Controllerのように、半ばFWの住人と直接やり取りするようなところでは、わりと直で使ったりもする
- HTTP Requestのラッパー的なクラスとか
- 必ずしもIF経由で完全分離していなくても、内部でコッソリ使う分にはまあ良いんじゃない？派
- IFとして、サードパーティへの依存が露出しなければ概ねOK的な
- PHPだと、引数や戻り値で `Chronos` とか `Carbon` を直接返さないで `DateTime` か `DateTimeInterface` 使ってね、内部計算で使うのはご自由に、的な感覚

### 9.5.7 質問
- > シンプルな設計は重複を削除して変更のスコープを制限することによって、任意の変更を可能にしている
- シンプルな設計で変更容易性を高めることによって必要になったときに必要な変更がすぐできるようにするのがあるべき姿なので、YAGNI違反思想は基本的に全部これで~~論破~~解決したい。
- 実装時の変更容易性は上がっても、事前に頑張った時にも時間は掛かっていると思いました。

### 9.5.9　使用上の注意
- > 「シンプルな」が「最も速い」や「最も簡単な」を意味するのだと偽ってはいけない。:+1::+1:
- オブジェクト指向プログラミングや、SOLID原則の知識を共有していないと、「シンプルな」という意図や実装がイメージしにくいのかなと感じました。ここは本章でも説明しているとおりペアプログラミングで共有していくとよいかもしれないですね。:+1:

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

## 疑問・参加者に聞いてみたいこと :+1:

### 9.5.1 YAGNI
- 皆様の設計し過ぎて実際にやり過ぎてしまった例を聞いてみたいです！ :+1::+1::+1:
- [discord](https://discord.com/channels/767540649418686486/774111081634332673/797791483629142046)
- 「先々の考慮」という言葉とYAGNI違反をどう折り合いつけてますか？ :+1::+1::+1::+1::+1:
- [discord]()

### ケント・ベックの考えるシンプルさ - p.338
- 「シンプルさ」って結構定義難しいと思いました、他に良い定義があったら教えてください:+1::+1::+1:
- [discord](https://discord.com/channels/767540649418686486/774111081634332673/797799424440664095)
- > ケント・ベックはシンプルな設計のことを、テストにパスして、次の4つのガイドラインを満たすコードのことだと説明した。
- この説明に引っかかる。Kent Beckの説明と変わってしまっているのでは。說明としては誤りに思う。
- > 最良の設計について定義すると、それはテストケース全部を実行させるもっともシンプルな方法である。この定義が効果的であるためには、一番シンプルな形とは何を意味しているのかを考える必要がある。(...)私がもっとシンプルだと呼ぶ4つのことは、以下の通りである。また、優先順位順になっている。(本書の引用通りなので略) - Kent Beck(2000)『XP エクストリーム・プログラミング入門』 p.110-p.111
- Kent Beckの話の組み立ては以下
1. "最良の設計"とは"テストケース全部を実行させるもっともシンプルな方法"である
- "シンプルな方法"と書いているけど、原文では `simplest design` なので、「シンプルな設計」と訳した方が適切そう（その方が、後続の文章とも上手くつながる）。
- 以降の引用部分では、 `「シンプルな設計」` という形で置換。
1. "私がもっとシンプルだと呼ぶ4つのことは、以下の通りである"
- "4つのこと"は略。本書の引用を参照。
- "テストケースを実行させるもっとも「シンプルな設計」"とは"最良の設計"についての定義であり、「シンプルな設計」についての定義ではない。
- 原文でも `the best design` の定義において `the simplest design` が使われているので、訳の問題でなく、両者は区別されている。
- > the definition of the best design is the simplest design that runs all the test cases.
- しかし本書の說明では、"最良の設計"が「シンプルな設計」に置き換えて說明されてしまっている。
- "最良の設計"と「シンプルな設計」を混同あるいは同一視している？
- 引用されている4項目も、「シンプルな設計」における「シンプル」が意味するところの說明であって、やはり"最良の設計"に対する說明としては対応するとは言い難い。
- 說明が対応していないので、「置換しても問題ない」とは言い難い
- "ケント・ベックはシンプルな設計のことを、(...)コードのことだと説明した"と、設計とコードが混同あるいは同一視されているように見えるのも気になる。
- 「シンプル」の說明で「コード」という言葉は使われているけれど、「設計 is コード」であるかのような說明は、Kent Beckはしていないように思う。
- 「Kent Beckの」として說明するには、問題が有るのでは
- 「筆者が解釈した〜」という說明ならば、引っかかりはすれども「あなたはそう解釈するのですね」で済ませても良い
- 「著者の考えるシンプルさ」であれば、あとは合意できるかどうかで、特に問題ない
- 色々と頑張ってポジティブな解釈や推測（あるいは妄想）をすれば整合させられないこともないのかもだけど（そんな気力も意欲も無い・・・）
- ↑原文の比較めちゃくちゃありがたいtです！！:+1:
- Simple / Easy の違いは気をつけたい

### 9.5.2 一度、ただ一度だけ(Once and Only Once)
- > それから、コードが何を実現しようとしているのかといったことは考えずに、ただしつこく重複を削除してみよう。 - p.339
- Martin Fowlerの言葉だけど、この說明はどうなんだろう
- 実際、本書では"さらにこの考えを進めたもの"として、"すべてのコンセプト"という言葉が使われている(p.339-p.340)
- 『新装版 達人プログラマー』だと、"単一、かつ明確な、そして信頼できる表現になっていなければならない"としているのは"知識"であって、「コード」ではない:+1:
- > すべての知識はシステム内において、単一、かつ明確な、そして信頼できる表現になっていなければならない。 『新装版 達人プログラマー』 2章 達人のアプローチ/7 二重化の過ち
- コードの意味（＝そのコードがどんな"知識"を表現しているか）を考慮せず共通化しようとするのは、むしろ~~アンチパターンとして~~良くない方法としてよく語られるような気がする:+1::+1::+1::+1::+1:
- [discord](https://discord.com/channels/767540649418686486/774111081634332673/797796993283784704)
- :memo: DRY原則は、「オブジェクトの責務において」という言葉が今は増えたのでは。
- :memo: 「DRYの濫用」

### 9.5.10 代替案 - P.343
- この本が書かれてから大分経っているが、2021年現在でもこの考え方が常に適用できるのだろうか？ 向き不向きや、ここは予測しとけとか、ここは大掛かりにやっておけとか等、知識の集積や時代の流れによる変化は生まれていないか？:+1::+1::+1::+1::+1::+1:
- [discord](https://discord.com/channels/767540649418686486/774111081634332673/797789134252933141)
- :memo: Fail Fast は 防御的プログラミングの話？ https://speakerdeck.com/twada/php-conference-2016
- DRY原則なんかは構造化プログラミング時代からオブジェクト指向プログラミングになって`オブジェクトの責務の範囲において`という注釈がついたようなイメージですね
- :memo: 今回、ガンマとのインタビュー部分読んで、 YAGNIで戒めたかったのは「要求に由来しない推測」ということなのかな
- :memo: ↑を戒めたいのであって、未来を考える事自体を一般に否定するものでないということであれば納得かな という感覚
- :memo: むしろ、YAGNIの大義名分の下に、手間がかかりそうなこととかちゃんと考えないといけないこととかを先送りしてしまおうという雰囲気がいろいろなところで目に付くような気がするなー。
- :memo: [それはYGANIか? それとも思考停止か?](https://discord.com/channels/767540649418686486/774111081634332673/797790967263526912)

### 9.5.6 フェイルファースト- P.342
- 「誰もこれまで必要としなかったため動かないものに関して、事前にフェイルするアサーションを用意しておく。」実務的な勘所がイメージをもてていません。想定していない引数の状態を検知するためのアサーションを事前に仕込んでおくというという概念は理解できますが、やりすぎるのはYAGNIの原則に反しているような気もしていて、どのようなレベルで事前に用意しているのか、お伺いしたいです。:+1::+1:

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

### (このプラクティスを使ったことがなければ)
- 何が簡単だと思ったか、何が難しいと思ったか、何が馬鹿げているように思ったか？
- これまで経験したものとどう違うか？
- 書かれているとおりに正確にやるには、どういう条件が当てはまっている必要があるか？

### (このプラクティスを使っているなら)
- 自分がやっているプラクティスは、本書に書かれているもの突どんな点が違っているか？(気づいたことだけでいい、理由はいらない)
- もし書かれているとおりに従うと、何が起こると思うか？
- コストの削減と納期の短縮。今提供するあたって必要最低限の設計と実装になるので、先回りの設計や実装を避けられます。※もちろん、現状の実装が変更容易性を保持していること、ユニットテストが書かれていることが前提になりますね。
- このプラクティスについて新しい洞察を得るために、お試しでやり方をどこか変えてみることはできそうか？(プラクティスが不適切だということを多足噛めるために、お試しでやってみるのは良いことだ)

## 振り返り

- [discord](https://discord.com/channels/767540649418686486/774111081634332673/797808638630035457)

## 放課後

- [discord](https://discord.com/channels/767540649418686486/774111081634332673/797815203144269824)