# ちょうぜつ本_読書py[5] みんなのメモ
###### tags: `ちょうぜつ本`

- このメモはWebに公開されています（HackMDチーム）
- リンクを知っている人は見られます
- HackMDにログインして編集できます

## ちょうぜつ本

- [ちょうぜつソフトウェア設計入門 ――PHPで理解するオブジェクト指向の活用](https://gihyo.jp/book/2022/978-4-297-13234-7)
- [サポートページ](https://gihyo.jp/book/2022/978-4-297-13234-7/support)（正誤表）

## お願い事項

(1) 今を楽しもう（録画はしないでね）

(2) 本メモは**インターネット上に公開されています。**
そのため、文章の丸写し（!=引用）や、書籍を読まずに内容が詳細に分かる表現は行わないようにしましょう。

参考記事:

- [Qiita ヘルプ 著作物を引用する際の注意点
](https://help.qiita.com/ja/articles/about-copylight)
- [Qiitaで記事を公開するときに気を付けるべきマナーについて 〜無断でネットや書籍の内容を丸写しするのはやめよう〜
](https://qiita.com/jnchito/items/215c2d51599eb29adabc)
- [文化庁 著作物が自由に使える場合
](https://www.bunka.go.jp/seisaku/chosakuken/seidokaisetsu/gaiyo/chosakubutsu_jiyu.html)

## このメモについて

このメモは ちょうぜつ本_読書py[5] のメモです
https://pythonista-books.connpass.com/event/295265

読む範囲： 6章後半（6-5以降）

## 読書会の流れ

* 20:00〜20:30 **自由参加**のもくもく会（個人作業）
- 事前に読む時間がとれなかった方はここで読んじゃいましょう（ざっとで大丈夫です）
- 合わせて、この**HackMD**に話したいことを各自書いてください
- ログインすれば書ける設定にしています
- ここがわからん、ここはわかった　お気軽に書き込んでみてください
- HackMDの書き込みに投票し、みんなが気になるところをわいわい読み解いていきます
* 20:30〜22:00 読書会本編（みんなでわいわい）
* Discordでスライド共有して別途案内します
* 20:30開始の本編では、「わたしこれ気になる！」
という話題に `:+1:` と書いて投票します。
* :+1: する上限はありません。
気になる話題に全部 :+1: しちゃいましょう。
ただし1つの話題には1個だけ:+1:でお願いします
* 票数が多い話題から話していきます。

## 以下、もくもく会ワークゾーン

以下は各節で「これってどういうことなんだろう」「ここからこういう気付きがあった」などを書き出すゾーンです。

### 第6章 テスト駆動開発

_章よりも細かい目次は公開されていないようですが、読書会運営都合により見出し番号だけ記載しています_

章全体への書き出しはこちらに

- テストコードを動作するドキュメントとするアプローチも知ったのですが、ちょうぜつ本とはまた別のテストとなりました :+1:
- https://www.youtube.com/live/Q-FJ3XmFlT8?si=r9pRpwXXSEOH_CYJ :+1:
-
-

### 6-5

- まずは動くところからだ！と思って急いで書くと結果的に、回帰テスト（=動作確認）で時間がかかってしまうので、早めにテストを書くのって大事だなと思いました:+1::+1:
- テスト書くの慣れないと、テスト書くのに時間かかるから、一般に浸透していないんだろうなと
- コアとなる部分は必ずテストコード書くべきっしょってなる
- あえて書かないのか？忘れて書かないのか　雲泥の差
- 1つのメソッドに全部の仕様を書いたので、アサーションルーレットしてると思われます :+1:
- テスト駆動開発（テストファースト）は、脳内にある実装を一発で書かせない制約をかけてるんだなーと思いました:+1::+1:
- 一発で書くとテストがなくて、機能追加したいときに書いた人を呪うことになる
- 仕様変更で、コード書いて辻褄わ合わせてから、テスト書いてる（今
- テストと実装の乖離が大きくならないうちにテストファーストで乖離をなくす制約によって統制かける感じ
- 抽象概念を意味継承した具象を付け足したい時とか、安心して追加できるし
- あと安心してドメインモデルの改善もできる
- TDD！TDD！！
- 前回は本当はテスト駆動の話がしたかったんだと気づく
- リファクタがないのがnikkieはちょっと気になった
- Red - Green - Refactor
- RedとGreenだと動作させるコードだらけになっちゃうんですよね。毎回Refactorは私は必須だと思ってます（『Clean Craftsmanship』Uncle Bob）
-

### 6-6

- コードを書いて、思っていない挙動をして考慮不足に気がついて修正をして・・・ という私からしたら、身につままされる話だ・・・
- 紹介されている仮説化（？）の考え方、一席一丁にできるものでは無さそう・・・（？） :+1::+1:
- モックを使えば具象なしでも抽象を検証できる！:+1:
- 抽象&モックのアプローチ、初手でできるかなあ
- テストファーストってことよね
- UML図と組み合わせると効果が高いですね:+1:
- 〇〇駆動とTDDはお互い否定し合うものじゃないんじゃよ（後方腕組み老師っ面

### 6-7

- まだ全部理解しきれていないけど、自分が知っていたテスト駆動開発より一歩先のレベル感？な気がした
- テストが書きやすいコードにする = 良いコードになった、というのはあれど、抽象を見つけ出せる・・・ みたいなのはすごいなと思った:+1::+1:
- DRYってよく考えないと間違えやすい。「似ている≠同じ」:+1::+1:
- ↑めっちゃわかる実は異なるタイミングで変更されるとか
- よくやられがちなのが、各事業戦略で【耐久能力】ケイパビリティみたいなのが共通であった際に、すぐにまとめられてしまうこと。いやいやKPI指標変わるのタイミング違うやんけって。
- 重複コード＝悪って固定観念が招く災い
-