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

# 開催概要

* 日程: 2022/12/10 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
### discord開始地点
https://discord.com/channels/432531367427964929/898843794101911622/1051108278681206855

### 感想
> これらの利点は、どれほど有効であったとしても、より深層にある目的の代理でしかありません。 - p.238

- 表現の問題かもだけど、個人的には「目的の代理」というより「副次的な結果」ぐらいの方がしっくり来る
- というか、そもそも「目的の代理」というのが何を意図しているのか、よくわからん
- 原文も"These benefits, however valid, are proxies for a deeper goal."なので、訳の問題ではない
- "proxy"という語感からは、後述される「真の目的」に辿り着く前に眼前に出現する（表層的な）効果・現象、みたいなニュアンスかなという印象を受ける :+1:

> p.239: テストがなかった場合にかかるバグの修正に必要な時間や文書を書く時間、アプリケーション を設計する時間などに比べて、テストの記述、メンテナンス、実行に多くの時間がかかるのであれば、テストを書く価値はありません。

- コストをいとわず品質を確保しなければならない場合、この主張は却下されるので過言では。 :point_left: :+1:
- 「質とスピードはトレードオフ」に加えて、「スピードは質より優先される」というのを暗黙かつ強めに前提とした主張になってしまっている感がある :+1:
- 結果として、一見もっともらしいようで適用できる範囲はそれほど一般化できなくなってる感

> p.239: しかし、テストにコストがかかることの解決方法は、テストをやめることではありません。うま くなることです。

- これはほんとそう。下手であることの言い訳として、「コストが見合わない」といってしまっている場面が多々ある。
- 「テスト」をソフトウェア開発に関する任意の単語に置き換えてもだいたい成立しそう

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

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

> p.240 一度は把握していた説明を思い出させてくれるようなテストを書きましょう。

- RSpec や jest の example のテキスト、みんなこれをやってほしい・・・
- 「hoge を返すこと」 といった見たらわかることではなくなぜそうなるのかの理由を書いてほしい :+1: :+1: :+1:
- cf. https://speakerdeck.com/nihonbuson/tesutokodonihatesutofalseyi-tu-woip-meyou

> p.240: 良い設計は自然と、抽象注 1 に依存する、独立した小さなオブジェクトの集まりになっていきま す。

- たびたび「抽象」に言及しているけれど、抽象にもいくつかの方向性/軸があることには言及されないのよね。この書籍に限らず。この(どの)抽象を扱う業界において、「抽象」が抽象的(曖昧)なままに扱われている印象がある。 :+1: :sorena:
- :male-police-officer: 「"曖昧"を"抽象的"と言うな署の方から参りました」
- どうも。確信犯です。 :innocent:
- もしかして：故意犯 :point_left:

### 疑問

> p.240: 良い設計は自然と、抽象注 1 に依存する、独立した小さなオブジェクトの集まりになっていきま す。

- [トークパート](https://discord.com/channels/432531367427964929/898843794101911622/1051120596852953220)
- 具象に依存することが前提のコードを書いたら良くない感じですか？確かにテストどうやるんだ？とはなったけど… :thinking_face: :thinking_face:
- https://discord.com/channels/432531367427964929/898843794101911622/1051120596852953220

> テストとは、炭鉱のカナリアのようなものです。つまり、設計がまずければ、テストも難しいのです。しかし、その逆は必ずしも真ではありません。テストにコストがかかるからといって、必ずしもアプリケーションの設計がまずいわけではないのです。 - p.241

- [トークパート](https://discord.com/channels/432531367427964929/898843794101911622/1051127097285943357)
- 珍しく「逆は必ずしも真ならず」をちゃんと意識してるなエラい、と思ったけど、そもそも前段までの記述とこの箇所の主張が噛み合ってないしてないような……？結論は同意するけれども.
- 「テストのセットアップに苦痛が伴うのであれば、コードはコンテキストを要求しすぎています。...」という記述、むしろ形式としては「テストにコストがかかるなら、設計が悪いのだ」という主張になってない？
- 「コードがコンテキストを要求しすぎている場合、そのコードに対するテストのセットアップは苦痛を伴うでしょう」ならわかる.
- 「"つまり"がつまってない」案件のニオイ
- 「結論は同意」と書いたけど、ここで言う「テストにコストがかかるが、設計は悪くない」というケースは「テストが下手だからコストがかかっている」なのか……
- > 適切に設計されたコードに、できの悪いテストを書くことは、技術上十分にあり得ます。 - p.241
- ユースケースレベルのテストとか、APIレベルのテストとか、e2eのテストとか、そもそも広いコンテキストにおけるテストを作るときは、設計がどうであろうとコストはデカくなるのでは :+1: :thinking_face:
- この章って単体テストに限った話だっけ、と章題確認したけど、単に「テスト」か……
- この著者あるあるの主語デカ案件のかほりがする(^^; :point_left:

> p.241: しかし、その逆は必ずしも真ではありません。

- こういうことが言えるのに、どうしてこうも(ry
- ~~書いてるとき、ちょうどテレビかラジオのセリフにでてきて「カッコいいな、使おう」となっただけ説~~(ﾎﾞｿｯ(邪推 :kusa:

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

### 感想

### 疑問

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

### 感想

### 疑問

---

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

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

### 気づいたこと、気になったこと
- 「コストを下げる方法はやめることではなく、上手になること」というのは、こと技術に関しては大概通用する指摘だと思う. それが指摘されている点は良い
- for文ポインタに悩まされたあの頃を常に思い出していないと忘れそうな内容だから常に意識してないとまずそう。ある程度経験積むとコストだとかで判断してしまう問題。
- とか書いた直後で、言語仕様によってそもそも特定の技術を（言語の利用者は）意識しなくて良くなる、というコストの下がり方はあるなとも、ふと思った. これも案外主語デカ案件かもしれない(だとしたら、自分も乗っかってしまった(^^;
- ただ、「やめた方が総コストが下がる」というケースと、「上達した方が総コストが下がるケース」という区別はそれでも残る気がして、テストについては概ね後者なんじゃないかな、という気はまだしている
- 例え話に騙されない、の一方、迂闊に例え話使うとこうなるんだなーという自戒。　:+1:
- 脚注でも指摘されてしまっているが、「抽象」という語を便利に使ってしまっている結果として混乱を招いている箇所が...

### 疑問点

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

## 次回の課題
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)

# 次回