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

# 開催概要

* 日程: 2022/01/22 Sat 15:00〜17:00
* 会場: https://discord.com/channels/432531367427964929/898843794101911622
* [README](https://hackmd.io/sSmTRzcQSCuvqiO7uDUkFg)

# 課題図書

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

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

# 実施要領

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

# 当日までの準備
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

## タイムキーパー募集

今回の進行にあたり、タイムキーパー = タイマー設定を行ってくれる人を募集します。
「やっても良いよ」という方は、このコメントにリアクションをしてください :pray:
リアクションしていただけた方からランダムで選択します。

!timer 2

## 読書パート

- 範囲指定は節・項の単位
- 並行して、感想や疑問点をmdに書き込む
- 時間が余ったら範囲を超えて読んでも良いが、感想・疑問点を書き込むのは指定範囲まで

## 投票パート

- 議論したい箇所 → :thinking_face: 
- 議論したいわけではないが、共感した箇所 → :+1:
- 議論したい箇所を優先してピックアップ
- 共感した箇所は、議論したい箇所が終わったら、「特に話したいトピック」として提示されればピックアップ
    - 「特に話したいトピック」が提示されなければ、次の節へ
- :+1: は、スルーされる可能性あり. スルーされたくないテーマは :thinking_face: をつける

## トークパート
### :thinking_face: パート

- :thinking_face: 付きのコメントを優先
- :+1: は、「これを話したい」という指定が有れば話す
- :okawari: を投票した時、その後のトークを促進する意味から、理由を書けるとなお良い
  - 必須**ではない**。書けなくても/書かなくてもOK。「よくわからなくてモヤモヤするぐらいしか理由が書けない」という場合など。
  - 理由を書く場合も、**事後でOK**。投票してから理由を書き始める、でもOK

### :+1: パート
特に話したいトピックがあれば、任意のトピックを選択してトーク

### タイマー
トーク時間

!timer 10

:+1: 選択時間

!timer 2

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

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

# 読書メモ
## クラスが単一責任かどうかを見極める p.43-44
https://discord.com/channels/432531367427964929/898843794101911622/931821461126135858
> 今回は17:00も迎えたのでここまででとして、次回は「感想」セクションで取り上げたいトピックあるかどうかの確認から再開にしようと思います。
>
> トピックあればそれについてのトークから開始して、無ければ次の項へ進む、という感じで。

↓前回分
https://hackmd.io/-lWzUpXsSO-Lxq-mGilj8w#%E3%82%AF%E3%83%A9%E3%82%B9%E3%81%8C%E5%8D%98%E4%B8%80%E8%B2%AC%E4%BB%BB%E3%81%8B%E3%81%A9%E3%81%86%E3%81%8B%E3%82%92%E8%A6%8B%E6%A5%B5%E3%82%81%E3%82%8B-p43-44

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

### 感想
> p.43: 「あなたのタイヤは何ですか」(中略)不快な驚きを覚 えるかもしれません。
全体的に日本語を読み解けなくて何いいたいのか分からなくなった。

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

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

### 疑問

## 設計を決定するときを見極める - p.44-45
### discord開始地点
https://discord.com/channels/432531367427964929/898843794101911622/934339958813098044

### 感想

> p.44 未来にどんな機能の要求が来るかを知ってさえいれば、今日にでも設計についての完璧な決断 を下せます。

- 未来どころか、今ある機能の要求すら、出揃わないんだよなぁ……。:+1::+1::joy::innocent:
- 未来予知できるようになりたいと思った(無理)

> p.44 早い段階で設計を決定しなければ、という気持ちには駆られないでください。

- WF...
- What the F**k

> しかしGearは変更されるべきだという意見を擁護することもできます。どのクラスの構造も、アプ リケーションを将来メンテナンスする人たちに向けたメッセージなのです。構造は設計意図を明らかにします。良くも悪くも、今日確立したパターンは永遠に複製されていきます。 - p.45

- 『Clean Architecture』の「あなたのアーキテクチャは叫んでいるか」を連想した :+1:
- 名前だけでなく、クラスの構造やメソッドのシグニチャも、意図的にせよ無意識にせよ、何らかの「意図」「意味」を表現することは避けられない
- その基準が、ある人はドメイン知識だったりするし、ある人は配列処理のフローだったりする、という程度差は有る
- DDDなどは、そうした構造などに含める「設計意図」の基準として、ドメイン知識を積極的に(あるいはそれのみを)採用しよう、という態度と位置づけることもできるだろうか

> 自分以外のほかの開発者は、設計の意図はコードに反映されていると信じるものです。コードが嘘をついているときには、その嘘を信じ、広めてしまうプログラマーの存在に注意しましょう。 - p.45

- このあたり、最近はI/Fを切る時にちょっと意識することがあった
- ある地点にI/Fが切られている時、そこには以下のいずれかの意図が、少なくとも一つは有ると考えるのではないか、という点 :+1:
- 求められる振る舞いの詳細が、動的に変化する必要がある
- 今はバリエーションは無いが、今後、振る舞いの詳細が増えたり変化する可能性が高い or 予定されている
- 外部APIとの通信など、アプリケーション単独では制御不能な箇所がある
- 追加で、分業のための担当者間規約としてのインタフェースもある
- しかし、そうした意図が無く「可能性や具体例は不明だけど、何か有った時のためにとりあえずI/F切っておく」的にI/Fを切ってしまうと、実際の背景とコードが語る情報が食い違ってしまうのでは、的な
- jsの場合だと、再代入する予定が無いのに `const` ではなく `let` を使う、的なことかもしれない
- というような理由で、「I/Fを切る」というのも場合によってはここで言う「コードが嘘をつく」という事態を招きかねないな、と思ったのを連想した

> p.44: 未来は不確かであり、初期段階での知識量は、プロジェクト全体で いえば最も少ないのです。最も費用対効果の高い行動は、おそらくより多くの情報を待つことで しょう。
> p.45: 何もしないことによる将来的なコストがいまと変わらないときは、決定は延期します。決定は 必要なときにのみ、その時点で持っている情報を使ってしましょう。

- 過剰なアップフロントにならないためには、この割り切りは重要。
- と同時に、安易な先送りにならないように自分に問い続けることも合わせて大切。:+1::+1::+1:
- 実装としては現状を容認しつつも、その時点で想定される変更案は、コメントや設計書などに注記しておくのも、場合によっては有用。:+1:

> p.45: 良くも悪くも、今日確立したパターンは永遠に複製されていきます。

- 「こういう場合にはちゃんと変更するように」と指示してあってすら、変更を最小限にしてあっちこっちにしわ寄せが来るパターンは良く目にするので、つらみ。
- とりあえず「いまあるものと統一感あるように作ろう」はあるあるなので、わかる話。。。恐ろしい。

> 構造は設計意図を明らかにします。

- 断固、そうは思わんぞという構造を見たことあるぞ！！！！！！！！！ :kusa:
- 

> 自分以外のほかの開発者は、設計の意図はコードに反映されていると信じるものです。コードが嘘をついているときには、その嘘を信じ、広めてしまうプログラマーの存在に注意しましょう。

- 設計もリファクタリングも全員が持ちたい技術だよなあ… :+1:
弊社、その辺の知識は20人に1人くらいが持てば良くて、その人が20人分の面倒を見ましょうという主張らしくて目眩がしてる。
実装は生産じゃないんだよ、設計なんだよ！:+1::+1::+1:
- 「みんなが設計の知識や技術を持っていない」という「現実」とやらに対して、"じゃあそれを学ぼう（「現実」を変えよう）"ではなくて"だからしょーがないよね（「現実」だもの）"という思考の成れの果て感…… :+1:
- 「現実主義」という名の現状追認なアレ

> p.45 この「いますぐ改善」と「あとで改善」間の緊張は常に存在します。

- これは、どっちであるべきに偏って喋る人が多い気もするので、どちらが正しいじゃないのは意識する/意識させないとだ。:+1::+1:

### 疑問

- YAGNIな話でしたけど、どうやってその必要性・重要性を理解しました？チームに知識としてインプットはできても、腹落ちしてもらわないことにはうまくいかんなあという感覚があって、腹落ちレベルの理解のためにどんな経験・説明が必要なのかなーと悩み中… :thinking_face: :thinking_face: :thinking_face:
- [トークパート](https://discord.com/channels/432531367427964929/898843794101911622/934346123815051336)

> p.45 l.11 Gearは設計者の意図について嘘をついています。
> p.45 l.16 コードが嘘をついているときには、その嘘を信じ、広めてしまうプログラマの存在に注意しましょう。

- [トークパート](https://discord.com/channels/432531367427964929/898843794101911622/934340067743387658)
- 「嘘」とは。 :thinking_face: :thinking_face: :thinking_face: :thinking_face: :thinking_face:
- 著者自身は↓のあたりが念頭にありそう
- > Gearクラスの責任はどう説明すればよいでしょうか。「歯のある2つのスプロケット間の比を 計算する」というのはどうでしょう。これが事実だとすると、このクラスは、（現時点においても そうであるように）多くのことをやり過ぎています。おそらく必要なのは「自転車へのギアの影 - p.44
- 「設計者の意図」 = 「歯のある2つのスプロケット間の比を計算する」で、「嘘」は「（その意図に比べて）このクラスは、多くのことをやり過ぎてい」るという点、という風に読むことになるだろうか

> p.45: すべての選択には対価が伴います。

- [トークパート](https://discord.com/channels/432531367427964929/898843794101911622/934349841495126016)
- この選択には、様々な観点を踏まえてほどよいところに落とす、というバランス感覚が必要。ではそのバランス感覚はどう養うか。観点の候補の引き出しを多くしつつ、経験を積んで体感し、将来の予測をおぼろげながらも見えるようになっていくしかないようにも思えるけれど、いい方法があれば知りたい。:thinking_face: :thinking_face: :thinking_face:

# 次回実施
## 予定
2022/01/22 Sat 15:00〜17:00

## 再開地点

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

## 感想
### 気づいたこと、気になったこと
- 定期的に同じような話題（今回だとYAGNI）を自分で出してしまっている気がして、どうしようかなあという気持ちがちょっとある
- 少なくともこの会では「ガンガンいこうぜ」で :ok_hand:
- 2回話すと、前と違う話が出てくるので繰り返しも好き感。
- コメントもらって自分の脳が衰えてる悲しみ以外はスッキリしました！
- 設計難しい(定期)
- 結論なさそう？って議論でも、話してみると学びが出てくるのが嬉しい。:+1:
- 「次回繰越」の方式を固められそう
- 「次回で話したいトピックを予め挙げておく」:+1::+1::+1:

### 疑問点

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

## 次回の課題
[まとめ用mdに追記](https://hackmd.io/wfDfaf4nRQuPG1BYtcy_jA)