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

# 開催概要

* 日程: 2023/01/28 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.241_p.244
[前回](https://hackmd.io/14F-75o6TsubsXhrlF27qw?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_%E4%BD%95%E3%82%92%E3%83%86%E3%82%B9%E3%83%88%E3%81%99%E3%82%8B%E3%81%8B%E3%82%92%E7%9F%A5%E3%82%8B_p241_p244)から繰越

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

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

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

* [トークパート](https://discord.com/channels/432531367427964929/898843794101911622/1068882745377423420)
* 意図がまったくわからない「メタファー」なんだが……。:point_left:
* 「メッセージの起源」?? 何処の話から出てきた?
* 原文も Origins of Messages...わからない。
* 前半にもあったけど、中途半端にアラン・ケイのメッセージングモデルを取り込んで説明しようとしている節がある
* ただ、やろうとしているのはあくまで「アラン・ケイのメッセージングモデルを取り込んだ説明」であって、「アラン・ケイのメッセージングモデル」を説明しているとは内容的に言い難い
* この表で言いたいことは完結しそう。
* 

> 受信メッセージは、そのその戻り値の状態がテストされるべきです。送信コマンドメッセージは、送られたことがテストされるべきです。...

- [トークパート](https://discord.com/channels/432531367427964929/898843794101911622/1068873710825656400)
- この認識を合わせるのとても大変、みんなどうしているんだろう
- つまるところ、ここで言っているのは↓のようなことっぽい
- パブリックインターフェースのみに依存せよ
- クエリ（戻り値を返し、副作用の無いメッセージ）は、その結果をテストせよ
- コマンド（副作用のあるメッセージ）は、それが送信されたかどうかをテストせよ
- クエリについて、それが送信されたかどうかはテストしてはならない（する必要が無い）
- これらを主張するために、唐突かつ中途半端に「メッセージ」という概念を引っ張り出す必要はあったのか、そもそも本文で試みられている説明方法が適切なのかどうかは、その内容とは別に疑問 :point_left:
- ホワイトボックスなテストは基本的にはしないほうが良い(内部構造に依存するので)という感じですか？ :thinking_face:
- ブラックボックステストがよいか、ホワイトボックステストがよいかは、テストの目的と内容によるかと。 :point_left:

### 疑問

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

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

## 9.1_意図を持ったテスト_いつテストをするかを知る_p.245_p.246

### discord開始地点

https://discord.com/channels/432531367427964929/898843794101911622/1068889086976327851

### 感想
> ｐ.245 テストを最初に書く意味があるのならば、いつでもそうしましょう。残念なことに、そうすることに意味があると判断するのは、初級プログラマーにとっては難しいこともあります。 :+1:

- 難しいうえにテストを最初に書くこと自体が難しくでできなかった(今もできない)
- %s/初級プログラマー/人類/ Hahaha :)

> 「テストとは再利用」であり、このコードの再利用はできないからです。 - p.245

- 「テストが再利用」というのは、言われてみれば確かに。だからこそ、TDDはプログラマを「最初の利用者」にするわけで。:+1: :+1:
- この表現に乗っ取るなら、「テストが難しい」は「再利用が難しい」と近似とも考えられそう。
- テストを書く意義として「再利用できるかどうかを実際に確かめる」という観点も、この表現からより強く押し出せそう

> p.245 そのため、初級の設計者はテストファーストでコードを書くことが最も有益です。

- テストできるコードを最初から書くのは難しいので、新人にはいつも最初にTDDブートキャンプ動画見てもらってる。いきなり3h動画はきついかも？と思いつつ。 :clap:

> 適切な意図を持った初級者はしばしば、コストが高く重複のあるテストを、散らかって、強固に結合されたコードの周辺に書きます。
- Well-intentioned novices often write expensive, duplicative tests around messy, tightly coupled code
- 「適切な意図を持った初級者 = Well-intentioned novices」
- https://www.ei-navi.jp/dictionary/content/well-intentioned/
- > しばしば良くない結果を招くものの、善意を特徴とする
- えぇ……（原文のニュアンスが迷子

> その複雑なコードには、対象のタスクが持つ複雑さではなく、プログラマーの経験不足が反映されているのです。 - p.245

- 対象が複雑だから複雑なのか、複雑にしかできない作者だから複雑になっているのか、という問題はジャンル問わずついてまわる…… :+1: :+1: :+1:
- 使い慣れていない言語を触った時に「こんな書き方出来るんだ！」となるソレも
- 言語やフレームワーク固有のルールを覚えるコストが高すぎて適切なテストを書くまで時間がかかる問題ある、かといってそれらを無視してシンプルに書きすぎても困るという
- シンプルに書こうとした結果、言語やFWの設計思想と合っていなくて、結果的に複雑になってしまって、こんなはずじゃ……ってなったり。 :+1:
- 目線を入れ替えて、実際に複雑な設計・対象だから複雑に見えるのか、シンプルな構造を理解できないから複雑に見えているだけなのか、というのも
- 抽象概念の理解、という話題の方が適切かも

> p.245: そういった初級者がつくった複雑すぎるアプリケーションは、不屈の努力のたまものとして見られるべき

- 「動いてえらい!」の評価はわすれないようにすべき。 :tada:
- レビューでは、未熟さに対して否定的にコメントせず、改善のための批判的な視点から個々の問題点を整理するようにしたいところ。

> MiniTest で書かれたテスト例はRuby1.9以上がインストールされている環境であればどこでも動作するから

- テストを実行する手軽さほんと大事だと思う

> 自身の強みを過大評価し、肥大した自己像をもって、テストをしないことの言い訳にしてはいけません。

- どちらかというと、時間やマンパワーの不足の方が、理由として挙げられることの方が多い印象 :+1:
- ここでの「テスト」が「自動テスト」を指すのだとして

### 疑問

## {読書範囲}

### discord開始地点

### 感想

### 疑問

---

# ふりかえり

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

## 感想

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

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

- 今回の範囲、割とアカン翻訳があって残念…… :+1: :point_left:
- 「状態」とか、「適切な意図を持った初級者」とか
- 「状態」のモヤモヤが解決したのスッキリした、原文読めないと辛い...
- オライリー が なかまになりたそうに こちらを みている |∀・）
- https://learning.oreilly.com/home-new/
- 「宇宙船」だったりやや中途半端な「メッセージ」の再導入だったり、引っかかるところは残りつつも、ここで言及されている観点は良い内容だったという感想 :+1:
- 内と外の区別・隔離
- コマンド・クエリという区別に基づいたテスト観点の分類
- メタファは、口頭だったりは通じるんだろうけれど、文面になると混乱の元になりやすいですね。 :point_left:
- 使い方も微妙だったなあと。せっかく「宇宙船」というメタファを使ったならそれに基づいた例や説明をすれば良いのに、言いっぱなし……(^^;
- わからないなって時、原文と、他の場での著者の話っていうのは方法として頭に入れておくのが良さそう。 :+1: :+1:
- シンプルさを求めた結果重要な情報が抜け落ちると大変なことになる。 :point_left:
- Kent BeckがSimplicityの条件に「理解するために必要な情報が全て揃っていること」を含めていたの好き（確かXP本. これについては初版・二版両方同じこと書いてたはず） :+1:
- 少なきゃ良い、というものでも無いというアレ. 削った結果必要なものまで落ちれば「シンプル」以前の問題. :+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)

# 次回
https://hackmd.io/ReWH-TMHRP6JeF9SIlHK1w?edit