Link
Embed
Share
Beginning
This slide
Copy link URL
Copy link URL
Copy iframe embed code
Copy iframe embed code
Copy javascript embed code
Copy javascript embed code
Share
Tweet
Share
Tweet
Slide 1
Slide 1 text
プログラムと 名前にまつわる 雑談会
Slide 2
Slide 2 text
自己紹介 ● 名前: Akira Nakano ● 趣味: ボビンレース(はじめたばかり)
Slide 3
Slide 3 text
雑談会 プログラムと名前に関係するお話をつらつらと
Slide 4
Slide 4 text
名前と設計に関する考え (自分の)
Slide 5
Slide 5 text
名前と設計に関する考え 「雑談」で話す理由 ● 設計って一つの視点で行うものじゃない ● ユーザー, 開発者, フレームワーク, 実行環境, etc… ● 同じ題材でも求められるものが違う ○ 実在するお店のシステム ○ ゲーム内の武器屋
Slide 6
Slide 6 text
名前と設計に関する考え 「雑談」で話す理由 名前のみでは語れない、でも名前を考えることは大切 なので、若干無理やりな部分も! (収まり切らなかったとかじゃないよ！)
Slide 7
Slide 7 text
名前と設計に関する考え ちょっと名前から外れて、良い設計とはなにか？ ● 疎結合が良い ● 高凝集が良い よく聞く話、なぜか？(というかなに?)
Slide 8
Slide 8 text
名前と設計 家が一つのパーツでできていたとする
Slide 9
Slide 9 text
名前と設計 窓が割れたら？
Slide 10
Slide 10 text
名前と設計 交換が効かない、全部捨てるしかない
Slide 11
Slide 11 text
名前と設計 逆に必要以上に細かく別れていたら？
Slide 12
Slide 12 text
名前と設計 求められる性能を発揮できない
Slide 13
Slide 13 text
名前と設計 ドアに連動して屋根が開いたら？
Slide 14
Slide 14 text
名前と設計 他の部分も怖くてさわれない
Slide 15
Slide 15 text
名前と設計 機能性(高凝集) と 独立性(疎結合) が求められる
Slide 16
Slide 16 text
名前と設計 プログラムも同じ 全部同じクラスやメソッドに書いてしまったら ● 仕様変更となったとき ● 不具合が見つかったとき ● 新しい機能を導入したいとき 適切な粒度で変更できますか？
Slide 17
Slide 17 text
名前と設計 プログラムも同じ 逆に複数の処理を跨がないと機能を達成できないとしたら ● 修正があったとき全て対応できるか ● 間違った使い方をしないと保証できるか ● 他の処理によって予期せぬ動作を引きおこなさないか 機能性を担保できますか？
Slide 18
Slide 18 text
名前と設計 適切な境界 ≒ 適切な名前 が必要！
Slide 19
Slide 19 text
名前と設計 バーガーショップの販売を模した処理を考えてみよう (Mのつくあのお店) ● 要素をクラス化すればいいよね ● 名詞で名前を付ければいいんでしょ？ ○ お店 ○ カウンター ○ キッチン ○ お客さん
Slide 20
Slide 20 text
名前と設計 バーガーショップの販売を模した処理を考えてみよう (Mのつくあのお店) ● 要素をクラス化すればいいよね ● 名詞で名前を付ければいいんでしょ？ ○ お店 ○ カウンター ○ キッチン ○ お客さん 本当か？
Slide 21
Slide 21 text
名前と設計 なんとなくこんな感じかな? お店 キッチン カウンター お客さん
Slide 22
Slide 22 text
名前と設計 「販売」はどこだ？ お客さん 販売 お店 キッチン カウンター
Slide 23
Slide 23 text
「販売」ってなんだ？
Slide 24
Slide 24 text
名前と設計 ● 「販売」ってなんでしょうか？ ● 名前は知っている ● なんとなくお客さんとお店のやりとりだと思う ● 本当にそうか？ 境界線が曖昧(少なくとも、今の自分の中では)
Slide 25
Slide 25 text
名前と設計 名前「販売」について考える ● メニューを見せる ● 注文を受ける ● 注文をキッチンに伝える ● お金のやり取りを行う ● 商品番号を渡す ● 商品番号に紐づく商品を渡す 「お店」は出て来なかった(お客は隠れているだけかも)
Slide 26
Slide 26 text
名前と設計 販売 キッチン 番号 商品 注文を受ける 商品を渡す 注文 メニュー 見る
Slide 27
Slide 27 text
名前と設計 悪くなさそうだけど 販売 キッチン 番号 商品 注文を受ける 商品を渡す 注文 メニュー 見る
Slide 28
Slide 28 text
名前と設計 名前からの考え方 ● 「販売」という名前に自分は戸惑った ○ 他の人はどうだろうか？ ● 「販売」という名前は他の機能を持たないだろうか ○ 「商品券」の販売は？ ○ メニューの切り替えがあったら？ ○ 不要な機能に違和感を示す名前か？
Slide 29
Slide 29 text
より独立した名前を探そう
Slide 30
Slide 30 text
例えば、こんなの
Slide 31
Slide 31 text
名前と設計 ● メニュー提供 ● 注文カウンター ○ 注文を受ける ■ 注文が正しいか確認する ■ 注文をキッチンに伝える ■ お金のやり取りを行う ■ 受け取り番号を発行する ● 提供カウンター ○ 商品の提供 ■ 受け取り番号が必要 ■ 商品が完成していれば提供する
Slide 32
Slide 32 text
名前と設計 注文カウンター キッチン 提供カウンター 注文 番号 商品 メニュー
Slide 33
Slide 33 text
名前と設計 注文カウンター キッチン 提供カウンター 注文 番号 商品 メニュー あれ？「販売」は何処へ・・・
Slide 34
Slide 34 text
販売 名前と設計 注文カウンター キッチン 提供カウンター 注文 番号 商品 メニュー 組み合わせて表現 ちょっと怪しい、まだふんわりしてる
Slide 35
Slide 35 text
名前と設計 注文カウンター キッチン 提供カウンター 注文 番号 商品 スペシャル メニュー 変化があっても受け入れられる A B
Slide 36
Slide 36 text
名前と設計 ● 目につく名前に惑わされない ● 名前(境界)を理解する ○ フォーカスしたい名前の本質を知る ● より小さい概念(の関係性)を見つける ○ カウンターは物理的には1つかもしれない ○ 概念としては「注文」「提供」の二つがある ● 可能なら具体的な名前を付け直す
Slide 37
Slide 37 text
ここから本当に雑談
Slide 38
Slide 38 text
名前に迷ったとき ● つぶやいてみる ○ 販売は商品を提供する。販売はメニューを変更する。 ○ 提供カウンタは商品を提供する。提供カウンタはメニューを変更する。 ● となりの人に聞いてみる ○ 2,3人が首を傾げなければ、たぶん大丈夫 ○ できれば会話してみると良い ● 英語に迷ったとき ○ 日本語 > 翻訳 > 画像検索 ○ 試している最中
Slide 39
Slide 39 text
ハンガリアン記法 ● 昔話！！ ● Microsoftのチャールズ・シモニイにより考案された ● ハンガリー人らしく、そのままなネーミング ● それが保持するものの種類を示すタグを小文字で付ける
Slide 40
Slide 40 text
ハンガリアン記法 ハンガリアンは二つある ● システムハンガリアン ○ 一般に知られる(知られた)ハンガリアン ○ 暗黒面 ● アプリケーションハンガリアン ○ シモニイが本当に提唱したかったもの
Slide 41
Slide 41 text
ハンガリアン記法 ● システムハンガリアン ○ 変数の型を表現するタグをつける ○ int なら i, long なら l とかで iCount, lCountとする ○ 型があれば保証してくれる情報じゃない？ ○ その変数の型が変更された時に保守が大変 ■ 逆に混乱の元になる ○ 推奨されない
Slide 42
Slide 42 text
ハンガリアン記法 ● アプリケーションハンガリアン ○ 変数の種類を表現するタグをつける ○ 安全な文字列ならsafeのs、逆ならunsafeのusなど ○ 型では保証できない領域を保証する ○ sPassword = usPassworld 危険なコードが見える ○ 現在は推奨されない(とおもう)
Slide 43
Slide 43 text
ハンガリアン記法 ● 現在 ○ usというタグの意味を知らないと理解できない ■ 省略の問題が残る ○ us(タグ)よりunsafe(名前)の方が読み手を選ばない ○ 型の力を強化できる ■ strong typedefなどにより強力な型付けが可能 ○ 意思は受け継ぎつつ非推奨かなと思う
Slide 44
Slide 44 text
曖昧な名前 ● Get ○ プログラムは、データをやり取りするので至る所に「取得」がある ○ どこから取得したのか? どう取得したのか？ ○ 特にインフラレイヤでは気を付けたい(DBとかデバイス付近) ○ メンバのゲッター程度の軽い処理に対して記述されるもイメージ ● Check ○ チェックした後は？あっていればいいのか？間違っていればいいのか？ ○ CheckPost(ポストである確認) より AllowPostOnly(ポストのみ許可) ○ CheckBox->Check() チェックマークをつける？(ちょっと無理やり) ● Filter ○ 除外するのか、選ぶのか・・・Selectとかどうですかね。
Slide 45
Slide 45 text
ユビキタス言語 DDDのプラクティスの1つ 開発者とドメインエキスパートとの間で共通の意味を持つ用語を構築する 開発者とドメインエキスパートを含めたチーム全体で作り上げる共通言語 名前に業務上の境界を設け、開発者とドメインエキスパートが会話をし ドメインへの理解を深め、モデルに反映させる。 共通認識の名前を用いることで、課題に則したモデリングが行える。 バイト経験者と飲食店の例とかをやってみたら面白いかもね！
Slide 46
Slide 46 text
文化 ● 名前は文化から生まれる。 ● 勝手に命名ルールを変更するのは文化破壊となる。 ● 一人で進むのはやめよう。 ● チームで考える(やるべきこと、そうで無いもの) ● 文化がなければ、小さなところから育てよう
Slide 47
Slide 47 text
まとめ
Slide 48
Slide 48 text
まとめ ● プログラムと名前は切っても切れない関係 ● 今も昔も色々な考えがある ● 名前の考え方も進化していく ● 読みやすく品質の高いコードを目指しましょう ● 足並みそろえよう
Slide 49
Slide 49 text
以上、ありがとうございました