# 良いコード／悪いコードで学ぶ設計入門

## 第9章　P.179~201

- 任意参加
- ファシリテーター: kanazawa

### 話す・書く順番決めルーレット

in Ruby

['kawasaki','hsu', 'chen', 'teruya', 'kanazawa', 'okura', 'kanno'].shuffle.each { |v| puts ">[name=#{v}]\n\n" }

in JavaScript

const l = ['kawasaki', 'hsu', 'chen', 'teruya', 'kanazawa', 'okura', 'kanno']
l[Math.floor(Math.random()*l.length)]

### ファシリテーター決め方

- `%w(hsu chen teruya kanazawa okura kanno)`の順番でやっていく

### 参加者がやること
- 事前に決められた章を読む
- 学んだことやわからなかったことを書き込む（任意）

当日
- 最初に感想や質問を書く時間を設ける(10分)
- 時間枠 60分
- 延長枠 30分

### 勉強会時にやること

各自学びや気付き、疑問を発表していく
ファシリテーターがよしなに議論を進める
終了前に勉強会を振り返る？（KPTなどで）← 60分のときに仮締め

## 各自が書き込む場所

>[name=kanno]
- デッドコード
or 到達不能コード
可読性の低下
なぜ実行されないようなコードがあるのか読み手を混乱させる
前にExercise周りのコードに到達しないelse節があって大倉さんと削除した記憶

- マジックナンバー
定数として定義しよう
　 定数が複数ある時ハッシュにするかで悩むけどコンテキストによりそう？？

- 文字列型執着
　そんなことする人いる？！と思いました

- null
ruby の&.もアンチパターンですか…？？

- サンプルコードのコピペ
　鵜呑みにすると粗悪なロジックが誕生する
~~昔めちゃくちゃやっていたけど~~もうやらないな…

- 　銀の弾丸
　　 bestはない、常にbetterを目指す

>[name=teruya]

> デッドコード

p180 に載っているようなのってIDEで検知可能なんですかね…？

> 文字列型執着(p184)

そんなものは見たことがない

> nullを返さない、渡さない(p189)

よほどのことがない限り null: false をつけたい

> 例外の握り潰し(p191)

SIer時代にたまに見たｗ

>[name=okura]

### 9.1 デッドコード

デッドコードはRuboCopでも検出してくれるが、完全ではない。
https://docs.rubocop.org/rubocop/1.36/cops_lint.html#lintunreachablecode

### 9.2 YAGNI原則

重要だけど、見極めが難しい。後日の拡張に備えた設計は重要だけど、やりすぎると理解困難になりがち。

### 9.3 マジックナンバー

定数にしよう！

### 9.4 文字列型執着

見たことない…

### 9.5 グローバル変数

Rubyはトップレベルの定数がグローバルなので注意。

### 9.6 null問題

基本的に`nil`に頼りすぎない設計は重要。ただ、全ての箇所で`EMPTY`的なものを返すようにすると煩雑な感じになるので、バランス感が重要だと思う。

### 9.7 例外の握り潰し

例がやばすぎて笑う。
ちなみに、
https://ja.wikipedia.org/wiki/UNIX%E5%93%B2%E5%AD%A6#%E3%83%AC%E3%82%A4%E3%83%A2%E3%83%B3%E3%83%89:[…]F%E3%83%B3%E3%82%B0%E3%81%AE%E6%8A%80%E6%B3%95
にある「修復のルール」がだいたい同じことを言っている（つまり40年間くらい受け継がれてきた考え方）。

### 9.8 設計秩序を破壊するメタプログラミング

動的型付け言語であるRubyでは静的型付け言語とはちょっと考え方が違う。メソッドの呼び出しとかはIDEの支援を受けられないのでgrepする必要があって、そうなると動的に定義されたメソッドでも適切にコメントされていれば発見できる。
ただ、Deviseでの`current_user`みたいに動的に定義されたメソッドの発見が困難なケースもあるので難しい。
ただし、`instance_variable_set`とかは濫用厳禁。

### 9.9 技術駆動パッケージング

何を言っているのかよくわからない。
MVCは安定した構造であり、アプリケーションの寿命の中で変化しない。一方、ドメインの構造は変化する。ドメインの構造が変化したらディレクトリ構造を変更するのか？あるいは複数ドメインから参照されるファイルはどこに置くのか？

> ファイル単位で低凝集になってしまう

これも謎。これまで触れてきたシステムでファイル単位の結合や凝集について考えたこともないし考えている人を見たこともない。そもそも、コードの中でクラス名が明示されているのだからそのクラス名で検索すれば関連ファイルは一瞬で見つかる。
この節は多分本書で一番意味不明な箇所、読み飛ばすべし。

### 9.10 サンプルコードのコピペ

ぶっちゃけ、コピペ元を書いておいてくれさえすれば、後から意味が理解できるのでそれで十分かも。

### 9.11 銀の弾丸

https://ja.wikipedia.org/wiki/%E9%8A%80%E3%81%AE%E5%BC%BE%E3%81%AA%E3%81%A9%E3%81%AA%E3%81%84
名著なのでぜひ読んでみてほしい（ちなみに1986年の論文らしいので、こちらも40年近く昔の話だけど、今でも通じる）。

>[name=kanazawa]

- YAGNI
- Rewrites教師の給与明細の話
- マジックナンバー
- キャタル入った頃めちゃくちゃ注意受けた
- グローバル変数
- 今まで意識して開発したことない（むしろいつ使うのか）
- null問題
- Rubyならnil問題
- ぼっち演算子（`&.`）多用問題
- 例外の握りつぶし
- 見たことない。こんなの書く人ほんとにいるの？
- メタプログラミング
- プロダクションコードではあまり見かけない
- gemで使われることが多い印象
- サンプルコードのコピペ
- コピペ自体が悪いのではなく、何もわかってない状態でコピペをするのがダメ
- 銀の弾丸
- 良い言葉「設計にbestはない。常にbetterを目指す」
- 70〜80点くらいで出して早めにフィードバックもらう

## 振り返り

> [name=teruya]

たまに「そうはならんやろ」が出てくるのが興味深い

>[name=okura]

この章は癖が強い。「技術駆動パッケージング」だけは本当にわからん。

>[name=kanazawa]

- 今日はサクサク読めた

> [name=kanno]
- rubyのメタプロ系メソッドの名前が長い理由がおもしろかった

## 終了後ファシリテーターがやること
- 次回のファシリテーターを決める
- 大倉さん
- 読む範囲を決める
- 10章
- サクサク読んでいこうぜ！