リーダブルコード輪読会 第8章
===

# ディスカッションをより豊かにするためのグランドルール

- 参加者は毎回任意
- 途中参加・聞くだけでもOK！

- ページ数と同時に、節のタイトルやキーワードを記入してもらえると探す手間を省けて嬉しいです

- ファシリテーターや話している人は集中しがちなので、話していない人に議論内容をメモ:pencil:してもらえると嬉しいです

- 気になる質問や同感するものには :+1: を末尾につけてください。

- 社外秘情報は書かないこと!!!
- オープン設定で誰でも見れてしまうので

# タイムテーブル

| 時間 | 所要時間 | 内容 |備考 |
| -------- | -------- | -------- | -------- |
| 15:00 | 5-10分? | (書いてなければ)感想記入&書かれた感想・気づき・疑問をもっと掘り下げたいものを、 :+1: 付けていく | |
| 15:10? | 40-45分 | 本の節ごとにディスカッション | |
|15:55? | 5分 | 次回読む範囲決めてクローズ | |

## 下に感想などを書いていって下さい。どんな些細なことでもOKです。

---

# 序章、8.1 説明変数

## 感想・気づき
-

### 実践してる人
#### 書籍通りのやり方をしているか。または、何か違う点はあるか。
- 2回以上同じ値を使う(ことがわかった)場合は、すぐに検討する:+1::+1::+1::+1:

### 実践してない人
#### 簡単に導入できそうか。難しいと感じた場合は、何が引っ掛かりそうか。
-

## 疑問
- 1度しか使わない値を説明変数にするか
- 置き換えることで可読性は上がるが、メモリリソースを消費する問題が絡む
- 好み問題という気がするのでチームで方針を決める？

---

# 8.2 要約変数

## 感想・気づき
- 説明変数との違いはあまり意識してなかった(いずれも名付けの感覚なので)
- 説明変数は実践してたけど、要約変数はあまり意識していなかった。

### 実践してる人
#### 書籍通りのやり方をしているか。または、何か違う点はあるか。
- これも複数回使うような条件は検討する:+1:

### 実践してない人
#### 簡単に導入できそうか。難しいと感じた場合は、何が引っ掛かりそうか。
-

## 疑問
- 複数回使わない場合は冗長に感じるが、1回だけのときは使うべき？
- 個人的には1回しか使わなくても条件がわかりにくければ使う:+1::+1:
---

# 8.3 ド・モルガンの法則を使う

## 感想・気づき
- ド・モルガンと聞いてもピンとこないが、説明を読むと無意識に考えてる:+1:

### 実践してる人
#### 書籍通りのやり方をしているか。または、何か違う点はあるか。
- ド・モルガンを明確に意識しているわけではなく、否定形+and/orが絡む時は条件整理を意識する程度:+1::+1:

### 実践してない人
#### 簡単に導入できそうか。難しいと感じた場合は、何が引っ掛かりそうか。
-

## 疑問
- この条件をレビューするときに、チェックしやすい方法はある？
コードだけだと確認しにくいかも
- 机上だと見落としやすいから、UTかデバッガで境界値分析するとか
- :pencil: ベン図
- :memo: メソッドに切り出す > UT化
- :memo: 条件を1つだけにする > エラーの内容変える
---

# 8.4 短絡評価の悪用

## 感想・気づき
- 自分が読んでもすぐ理解できないので、そもそも悪い例のコードを書けない疑惑
- ↓あるある:+1::+1:
- 防ぐためには？
- タスクを小さくする
> そのときは「オレは頭がいい」と思っていたのだ。ロジックを簡潔なコードに落とし込むことに一種の喜びを感じていた。

- x = a || b || c　これどう扱う？
- 新しい人が見てわからない時どうするか
- 勉強してもらう > ペアプロで指導する
- 記法に名前がついてる時は調べてもらう
- 書かないのが良さげだが...どう書けばいい？
- 1つずつnullチェックをしていく
- 独断で決める？チームで相談する？
- １人でもいるなら相談
- レビュアーレビュイーで完結しがち
- 議論が白熱したら集合

### 実践してる人
#### 書籍通りのやり方をしているか。または、何か違う点はあるか。
-

### 実践してない人
#### 簡単に導入できそうか。難しいと感じた場合は、何が引っ掛かりそうか。
- 悪いコードをどう理解したか、箇条書きで書き出すと自然と改善例のコードになっていく気がする:+1:

## 疑問
-

---

# 8.5 複雑なロジックと格闘する

## 感想・気づき
- コード例だけ見た時は、"||"で区切って説明変数にすることを検討した
- このやり方だと可読性は改善されるので、そこで満足してしまうリスクがあるなと感じた
- 実際にコードを書いているときは気がつかないかも(複雑な条件だけを考えてしまう)。どうやったら気が付きやすいのか？
- 自分のコードなら考える、他人のコードなら考えないかも
- 自分のは意図を理解しているが、他人のはそうとは限らない
- 1つの条件毎に切り出す
- 他人に指摘まではしないかも
- 網羅性の結果を残す
- 優雅な手法がレビュアーに理解されづらい場合がありそう

### 実践してる人
#### 書籍通りのやり方をしているか。または、何か違う点はあるか。
- 局所解から考えてしまいがち、という思考パターンに気付いた
- [アーリーリターン](https://qiita.com/csharpisthebest/items/b935896f514f2f079b86)を使ってできるだけ見通しを良くするように気を付けている

### 実践してない人
#### 簡単に導入できそうか。難しいと感じた場合は、何が引っ掛かりそうか。
-

## 疑問
-

---

# 8.6 巨大な文を分割する

## 感想・気づき
- この流れでDRY原則が出てくるのは少し危ういなと感じた
- 「用途が同じもの」を共通化しているのであって、「ロジックが同じもの」を共通化しているわけではない点に注意
- 過去の自分はこれを混同し、共通化の地雷を踏み抜きましたorz
- DRY原則って初めて聞きました
- [クソコード動画 Switch文](https://twitter.com/minodriven/status/1228896043435094016)
- [解説スライド](https://speakerdeck.com/minodriven/kusokododong-hua-switchwen-jie-shuo)
- hi = "highlighted"と置くのはいいのか、、、
- 命名はともかく、変更箇所をまとめる意味では必要

### 実践してる人
#### 書籍通りのやり方をしているか。または、何か違う点はあるか。
- 文を分割したというより、名付けで簡略化したという印象なので、何か思考が違う気もするが言語化できない

### 実践してない人
#### 簡単に導入できそうか。難しいと感じた場合は、何が引っ掛かりそうか。
-

## 疑問
-

---
# 1/12はここから
---

# 8.7 式を簡潔にするもう1つの創造的な方法

## 感想・気づき
- Cを使ってた時は、四則演算マクロは定義していたが、積極的に使おうとしてなかったのはその通り
- 最近はこのレベルのロジックを更に読みやすくしたいという意識があまりなかった
- ちゃんと読めばわかるでしょという甘えがあるかも
- マクロ定義は泣きそうになりながら解析した思い出…一体何が有効なのか…
- ちゃんと言語仕様理解したら簡潔にかける場合もあるよ、と理解

### 実践してる人
#### 書籍通りのやり方をしているか。または、何か違う点はあるか。
-

### 実践してない人
#### 簡単に導入できそうか。難しいと感じた場合は、何が引っ掛かりそうか。
- (今は使ってないので)これが良いやり方だと言われてもモヤモヤは残りそう

## 疑問
-

---

# 8.8 まとめ

## 感想・気づき
- リネームや名付けは立派なリファクタリングなので継続的に実施したい

## 疑問
- 実装レビュー時に変数の名付けなど直さなくてもバグにならない箇所に指摘が多数出ると本質的でない（ロジックにバグがないか見てもらえているのか不安になる）と感じる。一方で保守性の観点から変数の名付けなども直すべきに思う。両方取りすると指摘反映多数でゲンナリする。どうバランスを取ったら良いか？
- :memo: 気づいたものは遠慮せず書いていく
- :memo: 観点を変えて何度かコードを読む > 時間はかかるが両取りできそう
- こう考えるきっかけの記事: [メンバーに恨まれそうな3つのコードレビュー施策を徹底したら、逆にメンバーが爆速で成長した話 - Qiita](https://qiita.com/gakuri/items/f4970aea8de5fa9bf016)
- :memo: 今回の範囲ではない、直すかは任意というスタンスで指摘
- :memo: ロジックを中心に見ていく、あまり可読性の指摘は少ない
- タスクの大きさの問題ではないと感じている
- レビューの目的、可読性は品質に含まれる？とか