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

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

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

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

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

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

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

# タイムテーブル

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

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

---

# 序章、4.1 なぜ美しさが大切なのか?

## 感想・気づき
- 美しさはリファクタリングのしやすさにも大きく影響が出るので大切にしたい
- 文章を読むようにすんなり読めるコードにしたい :+1:
- フォーマッターを使えば、チーム内である程度統一されるし、最低限インデントの間違いは防げる

## 疑問
- UIレイアウトの変更に伴い、タップイベントなどのメソッド配置を組み換えるまで徹底する？

---

# 4.2 一貫性のある簡潔な改行位置

## 感想・気づき
- ネットワーク遅延をjitter=イライラと表現することを初めて知った
- 簡潔に書いた例のコメント定義とそれぞれの定義箇所で","の後のスペース個数に一貫性ないのでは？というモニョり
- スペースの個数で揃えなくてはならないから書きにくそう
- こういうところは、書いているときはおろそかにしがちだけど、読む方の立場になると、ぜひやってほしい
- 最後の例は見かけた事なかったが、確かに見やすいかもしれない
- 後置コメントのフォーマット揃えるのは結構面倒
- 本当に変更したい箇所以外にも変更が必要になるから、できるだけ書かないようにしてる
- [改善できるツール](https://qiita.com/ayakix/items/3f05da9541b8e130e39f)もある

## 疑問
- なし

---

# 4.3 メソッドを使った整列

## 感想・気づき
- メソッド化で重複を解消した例だが、責務が同じかどうか意識して行うべきなので少し注意が必要 :+1:
- たまたまロジックが同じだからと共通化すると、目的の違いによりif/switchなど条件が増えバグの温床になりかねない
- メソッド化の際に行った情報の隠蔽は、設計におけるカプセル化にも通じる話でとても重要:+1:
- メソッド化の際は、命名に注意。やっていることを正確に表す名前にする
- テストツールによっては、どの`assert()`で失敗したかわかりづらくなる場合がある :+1:
- `CheckFullName()`の中の`assert()`だけ強調される場合もある
- 例のようなテストなら、[パラメタライズドテスト](https://qiita.com/uhooi/items/e5ee95c86f8d6734c6a7)の方が分かりやすく書ける:+1: :+1:

## 疑問
- なし

---

# 4.4 縦の線をまっすぐにする

## 感想・気づき
- 最初の例でも基本的に改行の方がいいと思うという個人的感想:+1::+1:
- スペースだと変更時に整列作業が増えるので、同じ目的なら改行の方が修正不要で好み
- 改行の方がどの引数を変更したか一目でわかるから好み
- これも、書いているときはおろそかにしがちだけど、読む方の立場になると、ぜひやってほしい

## 疑問
- なし

---

# 4.5 一貫性と意味のある並び

## 感想・気づき
- これはまあ普通こうやるよねという気がする。わざわざ上と下で順番入れ替える人はいないだろうけど、デバッグしてて順番乱れちゃってそのまま、ってケースはありそう
- `request`を`req`と略してる…
- まだわかるから良いか

## 疑問
- 4.1と同じ疑問、レイアウト依存の場合UI変更で組み替えする？
- :pencil: UIの順番が入れ替わった場合、合わせてコードの並び替えも行うか？
- :pencil: チェックが必要な場合はする
- :pencil: Flutter はコードがUIを表すので意識する必要がない。value は label と一対一なので順番を意識する必要がない
- :pencil: どこまで細かくするかはコストと効果のトレードオフで、認識が合っていれば良さそう
- 抜けや漏れを防ぐのに何か工夫してますか？ :+1:
- :pencil: それぞれで工夫はありそうだが、ケースバイケースだろう

---

# 4.6 宣言をブロックにまとめる

## 感想・気づき
- ブロック化は、関連ある塊を単位として定義するオブジェクト指向に通じる考え方な気がする
- 定義でこれをしなければならないという時は、その塊の責務が大きすぎるサインなのかも...
- 関数定義が必要な言語や、Javaのinterfaceならこういう分け方してあれば分かりやすそう
- 秘伝のタレのように、後ろに定義が追加されてるコードをよく見た気がする

## 疑問
- なし

---

# 4.7 コードを「段落」に分割する

## 感想・気づき
- ユースケースはどうしてもこうならざるを得ないので、できるだけ段落をつけて読みやすくしたいところ
- 段落わけした上で、関数に切り出せるものがないか見直すことが多い :+1:

## 疑問
- なし

---

# 4.8 個人的な好みと一貫性

## 感想・気づき
- こういうのは宗教に近いのでチーム規約として合意とるべき(良し悪し論で考えだすと戦争に...)
- 上に同意。規約を決めるときに熱い議論になりそうだけど。
- 規約が固まったチームに入ったときはできるだけ規約に従うようにしている

## 疑問
- :pencil: より良い書き方があれば、コード規約を変えるつもりで提案するくらいのスタンスでも良いかも
- :pencil: 言語でフォーマットが提供される場合もある
- 中括弧の位置でコンパイラの処理速度変わる？
- :pencil: 中括弧の位置で変わるかはわからないが、昔は char, int, 配列の宣言順で速度が変わる場合があった

---

# 4.9 まとめ

## 感想・気づき
- 行数が増える取り組みだが、可読性に大きく貢献するので、積極的にやっていくべきだと思う

> ある場所でA・B・Cのように並んでいたものを、他の場所でB・C・Aのように並べてはいけない。意味のある順番を選んで、常にその順番を守る。

- 意図を持って順番を変えないとならないなら、どうして変えないとならないか一目でわからないと辛いよなあ、と理解
- :pencil: `シルエット` という言葉イイネ

## 疑問
-