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

## 第13章

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

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

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=tsujita]
間違えてリファクタリングの章を読んでいたので今日は聞くだけ参加でお願いします・・

>[name=chen]

>[name=teruya]

> 現実世界での物理的な存在と、情報システム上のモデルが1:1になるとは限らず、1:多の関係になるケースがあることが大きな特徴(p.279)
> 目的駆動で名前設計することが、適切に目的達成するモデルを設計することにつながります(p.281)

1:1の時は毎回迷う…というかProfileモデルを切り出すのもそういうものだと理解しているけど、めちゃくちゃしっくり理解しているわけではない…。

>[name=okura]

### 13.1 邪悪な構造に陥りがちなUserクラス

この件はマネージャクラスが悪いのでは…？
ポイントとかは自分なら他のクラスに格納するけど、`User`クラスは作る気がする。

### 13.2.1 システムとは何か

> システムは目的達成のための手段なのです

ここで、システムが提供する手段はその上位システムの目的に対するものになっていることが重要。

Rubyでいえば、組み込みクラスを含めた言語システムがあり、その上位にRailsのようなフレームワークシステムがあり、その上位に個別のアプリケーションシステムがある。さらにフレームワークはデータベースのような外部のシステムと連動する。

システムは再帰的な構造をしている。

### 13.2.2 システム構造とモデリング

「モデル」という単語はアパレルでも用いられるが、その意味するところは各種具象を抽象したもの。服を着る人は無数にいるが、作成者が考える概念上の着る人がモデル。

システムにおいて「モデル」の概念を適用すると、実際に存在または動作するような具象が抽象化されたものとなる。

> モデルはシステムの構成要素

ではなく、モデルはシステム内にある下位システム。

### 13.2.3 ソフトウェア設計におけるモデリング

システム全体に対して「商品」の概念を適用しようとすると失敗するのはその通りで、やるべきことはシステムを下位システムに分割すること。

### 13.3 良くないモデルの問題点と解決方法

> 利用者の付帯要素が次々にUserクラスに追加され、一貫性が失われていきます

`Profile`クラスを作るみたいな工夫はよく見られる。

本章の「目的」は「下位システム」と言い換えられそう。

### 13.4 機能性を左右するモデリング

豚は食べられないので、このモデリングは失敗している😂

それはさておき、サバとサンマと豚の段階では正しいモデリングはできないので、判断を保留する必要がある。

>[name=kanazawa]

今回のUserクラスの話、RailsでDeviseを使ったらこの本で言うアンチパターンになってしまう？

RewritesのUserモデル

#  id                                                  :integer          not null, primary key
#  email                                               :string           default(""), not null
#  encrypted_password                                  :string           default(""), not null
#  reset_password_token                                :string
#  reset_password_sent_at                              :datetime
#  remember_created_at                                 :datetime
#  sign_in_count                                       :integer          default(0), not null
#  current_sign_in_at                                  :datetime
#  last_sign_in_at                                     :datetime
#  current_sign_in_ip                                  :string
#  last_sign_in_ip                                     :string
#  created_at                                          :datetime
#  updated_at                                          :datetime
#  role                                                :string           default("student_role")
#  name                                                :string
#  slug                                                :string
#  email_notification                                  :boolean          default(TRUE), not null
#  webpay_customer_id                                  :string
#  disabled                                            :boolean
#  description                                         :text
#  birthday                                            :date
#  is_usable_topic(false: cannot use, true: can use)   :boolean          default(FALSE), not null
#  is_usable_summary(false: cannot use, true: can use) :boolean          default(FALSE), not null
#  image_data                                          :text

そーだいさんによる「ぼくのかんがえた最強のユーザーテーブル設計」
[ユーザ情報を保存する時のテーブル設計 \- そーだいなるらくがき帳](https://soudai.hatenablog.com/entry/2018/05/01/204442)

ユーザー情報が肥大化したら「Profileクラス」として分けるのはアリだと思った。

- Profile
- birthday
- introduction
- etc...

> User(利用者)という名前があいまいな点 です。個人ユーザーとも法人ユーザーとも、どうとでも解釈可能で、大雑把でガバガバすぎる名前なのです

こう考えたことはなかったな。銀行のシステムとかだと必要になってくるのかな？

>[name=hsu]

13.3.5
システムは何らかの目的を達成するために作られるのであり、責務よりも目的が先に来るからです。目的はどう考えばいいでしょう？

## 振り返り
>[name=kanno]

1:1の場合のテーブル分けの話がしっくりきました

>[name=chen]

>[name=teruya]
0→1でアプリを開発する時は特にモデリングが難しそうです

>[name=okura]

久しぶりに社会システム理論の本を読み直したくなった（あれ長いんだよなあ）

ちなみにここに書くと、社会システム理論の本を読んだのは社会学者の宮台真司のゼミに一時期参加していたためです。首都大から家が近かったので大学は違ったけど潜り込んでいました。大学時代はカオス理論や複雑系の本も読んでいて、ある意味で人生で一番勉強した時期だったかもｗ

>[name=kanazawa]

この領域の話は本当に難しい。がっつりモデリングをやった経験がないと議論しにくい。

>[name=hsu]
モデリングする考え、その後classの設計する。
まずモデリングの概念は抽象的に一回runしないと分かりません。

## 終了後ファシリテーターがやること
- 次回のファシリテーターを決める
- chen
- 読む範囲を決める
- 14章