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

# 20201013

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

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

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

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

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

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

# タイムテーブル

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

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

---

# 序章、1.1 「優れた」コードって何？

## 感想・気づき
- p3 「前者の方が簡潔だ。でも、後者の方が安心できる」、読みやすさが心理的安全性に繋がる例で、直接目に見えないけど重要な影響を及ぼす
- 個人的に三項演算子は、条件かセットする値のどちらかが複雑だと使わないことが多いかなあ:+1:
- 行の折り返しが必要なくらい長くなるならif文などに書き直すことが多いです
- [簡潔に書こうとしてエンバグした例](https://qiita.com/tomohisaota/items/e6995e89b843e1295c08)

    if ((err = ReadyHash(&SSLHashSHA1, &hashCtx)) != 0)
        goto fail;
    if ((err = SSLHashSHA1.update(&hashCtx, &clientRandom)) != 0)
        goto fail;
    if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
        goto fail;
    if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
        goto fail;
        goto fail;
    if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
        goto fail;

## 疑問
- なし

---

# 1.2 読みやすさの基本定理

## 感想・気づき
- p3 「コードを理解する」=変更を加えたりバグを見つけたりできる、「言うが易し 行うが難し」なやつ...
- 障害解析などで全体を把握してる状態で書いたコードを、数ヶ月の自分が見てもよく分からんってなるパターンあるある
- 他の人=６ヶ月後の「君自身」かもしれないという言葉が印象的だった:+1::+1:
- :pencil: 6ヶ月どころか1週間後とか3日後とか

- 「コードは他の人が最短時間で理解できるように書かかなければならない」は、同意。他の人が読むもの、という意識は大事:+1:

## 疑問
- コードレビューでレビューアーとレビューイーで「読みやすい」の意見が真っ向対立したらどうしたらいいの？:+1::+1::+1:
### :pencil:
- T チームでたまにある。
- 「読みやすい」の基準やその書き方のメリットの認識がある程度揃っている必要がある
- 好みの問題になってくると第三者に意見を求めるなど
- 好みの問題だと、実装者に任せるチーム

---

# 1.3 小さいことは絶対にいいこと？

## 感想・気づき
- (そもそも2000行とかのクラスがあるなら、クラス設計の見直しする方が良いのでは？とか言いたくなるやつ)
- コードは短い方がいい vs 理解しやすい方がいい、が難しそう
- :pencil: 組み込み等ではパフォーマンス優先になる場合がある
- 短く書こうとすると、diffに気づきづらい場合があるから意図的に改行を入れる場合もあります

let nc = NotificationCenter.default
// 長いので、パラメータを変更した時に気づき辛くなりそう
nc.addObserver(self, selector: #selector(hoge)), name: UIApplication.didEnterBackgroundNotification, object: nil)

// パラメータごとに改行してあればどこに変更入ったか把握しやすい
nc.addObserver(self,
               selector: #selector(fuga),
               name: UIApplication.didBecomeActiveNotification,
               object: nil)

## 疑問
- なし

---

# 1.4 「理解するまでにかかる時間」は競合する？

## 感想・気づき
- Martin Fowlerのリファクタリングにも通じる話、基本的にメソッド内部の振る舞いを維持しつつ可読性を向上させるための話をしている
- p4 で言うリファクタリングは、一般定義のリファクタリングを指しているので注意
- Fowlerが紹介する、最も簡単なリファクタリングはリネーム
- :pencil: テストがないリファクタリングはリファクタリングじゃねぇ。とよく言う
- 名前も大事だけど、責務分担なども重要:+1::+1:
- 簡潔で明解な書き方をしていても、責務分けがあやふやだと混乱しやすい

## 疑問
- 一般定義のリファクタリングとそうじゃないリファクタリングを復習したい
- :pencil: 一般定義な方 > 変更はすべて含む rewrite, rearchitect, refactor
- :pencil: リーダブルコードで言っているリファクタリングは上記の refactor

---

# 1.5 でもやるんだよ

## 感想・気づき
- 「レガシーコードからの脱却」著者のDavidは、コードは完成した瞬間からレガシーコードとなり、時間経過とともに技術負債となると言ってる
- 気付いたら放置せず、直していくしかないのです...(そうしないと将来の自分が地獄を見ることもorz)
- :pencil: 「コードの臭い」 = 嫌な感じ。経験や本からの知識で嗅ぎとれるようになる
- :pencil: 「リファクタリング」という本おすすめ。
- 「でも、やるんだよ」の[出典](http://miztarnie.blogspot.com/2009/11/blog-post.html)
> 「な、こんな事無駄な事だと思うだろう。
> そうだよ、無駄な事なんだよ
> でもやるんだよ！」

## 疑問
- なし