オブジェクト指向設計実践ガイド読書会 - 第44回
===
###### tags: `オブジェクト指向設計実践ガイド読書会`

# 開催概要

* 日程: 2023/01/14 Sat 21:00〜23:00
* 会場: https://discord.com/channels/432531367427964929/898843794101911622
* [README](https://hackmd.io/sSmTRzcQSCuvqiO7uDUkFg)
* [タイムキーバー用テンプレート](https://hackmd.io/E0HZBN9OS9GBAtnsYXjDsw)

## 課題図書

『オブジェクト指向設計実践ガイド ～Rubyでわかる 進化しつづける柔軟なアプリケーションの育て方』(Sandi Metz 著, 髙山泰基 訳, 技術評論社)

- 技術評論社, pdf版あり
- https://gihyo.jp/book/2016/978-4-7741-8361-9
- Amazon
- https://www.amazon.co.jp/dp/B01L8SEVYI

## 実施要領

- 事前読書なし。都度その場で読んで、感想を書いて、議論する、を繰り返す。
- 参加スタイルは自由形。チャットでも音声でもご自由に。
- 主催はチャット参加です。

## タイマーについて
時間管理はタイマーbotで行います。
VCチャンネルに入っている人を対象にメンションが飛ぶので、VCチャンネルへの参加をお願いします。
また、タイマーは終了時に **音声がなる** ので、ご注意ください。

## 当日までの準備
1. 課題図書を手元に用意する
- 買う、借りる、etc(?)
2. 当日までに読んだり読まなかったりする
- 当日その場で読むので、事前に読んでおく必要は無し
- 気になったら事前に読んでおいても良し

---

# 当日の進行
## 進行フロー
https://hackmd.io/sSmTRzcQSCuvqiO7uDUkFg?view#%E9%80%B2%E8%A1%8C%E3%83%95%E3%83%AD%E3%83%BC

## :goti: or :okawari: について
- 各パートごとに :goti: or :okawari: を投票する.
- :okawari: が1つでも有れば、パートを続行する.

## 開催コール
https://1.bp.blogspot.com/-YrhlmWQ4uIQ/UrlmxoUdDeI/AAAAAAAAcLw/M6VFUKHnTos/s400/text_start.png

## タイムキーパー募集
https://hackmd.io/E0HZBN9OS9GBAtnsYXjDsw#%E3%82%BF%E3%82%A4%E3%83%A0%E3%82%AD%E3%83%BC%E3%83%91%E3%83%BC%E5%8B%9F%E9%9B%86

## 読書パート
https://hackmd.io/E0HZBN9OS9GBAtnsYXjDsw#%E8%AA%AD%E6%9B%B8%E3%83%91%E3%83%BC%E3%83%88

## 投票パート
https://hackmd.io/E0HZBN9OS9GBAtnsYXjDsw#%E6%8A%95%E7%A5%A8%E3%83%91%E3%83%BC%E3%83%88

## トークパート
### 議論(:thinking_face:)パート
https://hackmd.io/E0HZBN9OS9GBAtnsYXjDsw#%E8%AD%B0%E8%AB%96%E3%83%91%E3%83%BC%E3%83%88

### 任意トーク(:+1:)パート
https://hackmd.io/E0HZBN9OS9GBAtnsYXjDsw#%E4%BB%BB%E6%84%8F%E3%83%88%E3%83%BC%E3%82%AF%E3%83%91%E3%83%BC%E3%83%88

### 次回繰越(:eyes:)パート
https://hackmd.io/E0HZBN9OS9GBAtnsYXjDsw#%E6%AC%A1%E5%9B%9E%E7%B9%B0%E8%B6%8A%E3%83%91%E3%83%BC%E3%83%88

## 終了コール
http://3.bp.blogspot.com/-zgTNWF_hBmI/UZYlh9RhuDI/AAAAAAAATQ8/dymPl5P4eAs/s500/undoukai_relay_animal.png

# 読書メモ
## 9.1_意図を持ったテスト_テストの意図を知る_p.238_p.241
[前回](https://hackmd.io/ZcKSYMpeSYKoTTTWejvk5A?view#91_%E6%84%8F%E5%9B%B3%E3%82%92%E6%8C%81%E3%81%A3%E3%81%9F%E3%83%86%E3%82%B9%E3%83%88_%E3%83%86%E3%82%B9%E3%83%88%E3%81%AE%E6%84%8F%E5%9B%B3%E3%82%92%E7%9F%A5%E3%82%8B_p238_p241)残った :thinking_face: から

### discord開始地点
https://discord.com/channels/432531367427964929/898843794101911622/1063793875547865159

### 感想
> p.239: テストは、唯一信用できる設計の仕様書となります。

- これも過言では。テストは具体的なケースを列挙した「外延的な」仕様にはなるけれど、それを越えるものにはならない。どうあるべきかの条件を明記した (が実行可能ではない) 「内包的な」仕様を補完するものであるはず。:+1: :thinking_face: :thinking_face:
- 改めて時間をおいて見ると、「信用できる(reliable)」が著者的にキーポイントだったのかもしれない
- ここで言う「信用できる」が何を指すか、というのはあるが、文章の展開的には「事実に即していることが確実な」「確実に実態と合致する」ぐらいの意味合いっぽくはある :+1: :+1:
- ただし、テストコードがメンテされている場合に限る :+1: :+1: :point_left:
- なるほど、「（実際に実行されている）テストは〜」という但し書きも必要そう
- (実際に実行されている) が隠された仕様だった、と。テストコードにも仕様書にも書かれていなかった
- 自動テスト以外のドキュメントは、その意味においては確かに「信用できない」ものではあるが、さりとて「信用できる設計の仕様書」以外は不要、という話にまで広げないように注意する必要はある
- 「なぜそうなったのか」「なぜ〜にしなかったのか」といった過去だったり、「今後どのようになることを想定しているか」といった未来についてもテスト（に限らず、コード一般）は語り得ないので、それらについて補完するドキュメントも結局必要になる
- あ、本文は「設計の仕様書」か. その場合、↑のような過去・未来に関するドキュメントは「仕様書」に含まれない、という扱いは有り得るかもしれない. ただ、それであっても、そのように区切られた「仕様書」以外に何らかのテキストが必要ということは変わりないけれど.
- 「設計の仕様書」よりも「仕様の設計書」こそを残しておきたい。 :+1: :point_left: :+1:
- なるほど確かに、過去の取捨選択や未来への想定についての記録はまさしく「仕様をどのように定めるかの設計を記述した書」だ
- 「唯一」は言い過ぎにしろ、「テストは設計の仕様書になる」っていう意識は大事だと思う。なんか、淡々とロジック埋めになってるテストは...って。
- 「テストが設計の仕様書になる」は多分特に異論なくて、ただ、「テストが設計の仕様書になる」は「テスト以外の設計の仕様書は不要である」は何ら必然として含意はしないのに「唯一」とか行っちゃうアレ :point_left: :wakaru:
- 「AはBである」を「AだけがBである」と（著者が）誤認していそうなアレ
- 原文今持ってないんですが、やっぱり only とかになってるのですかね...
- :sob: "*Tests provide the only reliable documentation of design.*"　:sob:

> テストによって、設計の決定を安全に遅らせることができます。(...)テストがインターフェースに依存している場合、その根底にあるコードは、奔放にリファクタリングできます。 - p.240

- 今時点でわかっていることには対応しつつ、さりとて将来に対する予想・予期も「YAGNI」の名の下に切り捨てず、ある程度まで念頭においておくアプローチ、的な :thinking_face:
- 実際、「確定ではないが、実際起こりそう」というケースがある時、実際増えても検証できるように、という観点でテストを設計・実装することもやる
- 次の「抽象を支える」ともセット（[ここで言う「抽象」が何を指しているのか問題](https://hackmd.io/ZcKSYMpeSYKoTTTWejvk5A?view#%E7%96%91%E5%95%8F)はありつつ）

> p.241 設計の抽象度合いによっては、どんな変動であっても、テストなしで安全に行うことが不可能になります。

- 「脳内テストがあればいい」という人種の超人を除けば。それができてしまう人はいるけれど、ここに「凡人にとって」とか「コードの共同所有を前提にした場合」が入ると、この通り。

> p.241 テストとは、炭鉱のカナリアのようなものです。

- ものすごくどうでもいい話ですが、このたとえだと TDD ってカナリア大虐殺 :scream: :bird: :skull:

### 疑問

## 9.1_意図を持ったテスト_何をテストするかを知る_p.241_p.244
### discord開始地点
https://discord.com/channels/432531367427964929/898843794101911622/1063811051247902761

https://discord.com/channels/432531367427964929/898843794101911622/1063817081579126834
[次回](https://hackmd.io/VT6QJm4ZQd6t3mLT8Cr2jg?edit)に繰越

### 感想

> 彼らの手元には、巨大だけれども日付の切れた一連のテストがあるのです。 - p.241

- 原文だと `They have a big, but out-of-date test suite` なので、「日付の切れた」 = "out-of-date"
- 要するに、「古くなったテスト」ということね（よくわからない翻訳……

> テストから良い価値を得るための１つの単純な方法は、より少ないテストを書くことです。

- よし、アサーションルーレットを書こう...と、この言葉だけ人に伝えたらなってしまいそうだ。 :point_left:
- rspecならshared_exampleやshared_contextが乱用されるやつー

> p.242 l.2 テストから重複を取り除くことで、アプリケーションの変更に伴うテストの変更コストが下がります。
- 重複している部分すべてを変更しないといけなくなることを考えると、これを意識するのはかなり大切だと思った。 :+1:
- ここでの「アプリケーションの変更」というのは仕様の変更なのかAPIの変更なのかはわからないけど多分どっちも指すと思う。
- 「重複を取り除く」のが大事というのは特に異論無いが、テストにおいても「誤ったDRY」を踏まないように注意する必要はある :+1: :+1:
- DRYの適用を優先してしまって、「たまたまテストコードが似てるだけで、観点や前提は異なっている」というケースまで統合した結果、テストケースの追加が大変になったりテスト観点の把握が困難になったり（前科あり :+1::+1: :+1:
- テストコードに正しく「意図」を残せていないとやらかす感じですか？ :thinking_face:
- 本来観点や前提が異なるテストまでも「同じコード」で扱えるようにした結果、やたらとテクニカルなコードになってそれぞれのテストが置かれている前提・観点がコードから把握できなくなったり、前提・観点を変えようとしたら思わぬテストまで「前提・観点が変わった」ことにされてしまったり、となったりしました :+1: :+1: :+1::
- 上手く「前提・観点」が分かる形で実装しないと数か月後には「ここのコードが似ているから関数・メソッドに分離しよう」みたいになりそうで怖いですね。

> p.242: 図9.1: 宇宙船のよう

* 意図がまったくわからない「メタファー」なんだが……。:point_left:
* 「メッセージの起源」?? 何処の話から出てきた?

> 受信メッセージは、そのその戻り値の状態がテストされるべきです。送信コマンドメッセージは、送られたことがテストされるべきです。...
- この認識を合わせるのとても大変、みんなどうしているんだろう

### 疑問
> メッセージの戻り値について表明をするテストは、状態のテストです。 - p.243

- ここで言う「状態」って、誰のどの「状態」なのだろう :point_left: :thinking_face:
- 「メッセージの戻り値」と「状態」の対応関係がどうにも腹落ちせず、なかなかこのあたりの説明を飲み込めずにいる（そもそも説明として妥当なのかどうか） :handshake:
- > 送信メッセージの状態をテストする必要がないからといって、それらのテストをまったくしなくてよいというわけではありません。
- 「送信メッセージの状態」……？「状態」ってオブジェクトのものではなく、メッセージのもの？では、↑の「状態」とは……？
- 与えられた文字列を、とあるフォーマットに変換するという責任を負っていたら、その戻り値のフォーマットが所謂状態になるんですかね。
- 例えば、与えられた文字列をマークダウンにおいて太字にするという関数があるとしたら、実際の戻り値は太字になってますか？的な？
- メッセージを解釈・評価した結果を「状態」と言っている? 少なくとも、メッセージは発行された時点で不変なものではないか。 :thinking_face:
- リクエストに対するレスポンスへのテストだと思ってました。(HTTP的なそれで言うと)

## {読書範囲}
### discord開始地点

### 感想

### 疑問

---

# ふりかえり
- 感想/次回の課題それぞれで5分
- 要望に応じて :okawari:

## 感想
https://hackmd.io/E0HZBN9OS9GBAtnsYXjDsw#%E6%84%9F%E6%83%B3

### 気づいたこと、気になったこと

- 自動テストとそれ以外のドキュメントで位置づけが異なる前提条件は何か、というのはやりとりの中で明確になった感（大前提として、実行され続けていないと、というのを再確認 :+1: :+1:
- 本書の記述は（例によって）端的に不十分なので、補足は結構な量必要
- テストを通じた「決定の遅延」の（後で検証可能な形による）実践について、改めて言語化 :+1:
- 外部へのAPIの設計が大切という事を再認識した。
- なんで宇宙カプセルが出てきたか気になって仕方ない。:+1: :ne: :point_left:

### 疑問点
- 宇宙カプセル

### 仕事に活用してみたいこと

## 次回の課題
https://hackmd.io/E0HZBN9OS9GBAtnsYXjDsw#%E6%AC%A1%E5%9B%9E%E4%BB%A5%E9%99%8D%E3%81%AE%E8%AA%B2%E9%A1%8C

[まとめ用mdに追記](https://hackmd.io/wfDfaf4nRQuPG1BYtcy_jA)

# 次回
https://hackmd.io/VT6QJm4ZQd6t3mLT8Cr2jg?edit