たかが命名、されど命名。名前から考えるよいコード【タガヤス その４】発表資料(3) https://tagayas.connpass.com/event/80363/

1. プログラムと
名前にまつわる
雑談会

2. 自己紹介
● 名前: Akira Nakano
● 趣味: ボビンレース(はじめたばかり)

3. 雑談会
プログラムと名前に関係するお話をつらつらと

4. 名前と設計に関する考え
(自分の)

5. 名前と設計に関する考え
「雑談」で話す理由
● 設計って一つの視点で行うものじゃない
● ユーザー, 開発者, フレームワーク, 実行環境, etc…
● 同じ題材でも求められるものが違う
○ 実在するお店のシステム
○ ゲーム内の武器屋

6. 名前と設計に関する考え
「雑談」で話す理由
名前のみでは語れない、でも名前を考えることは大切
なので、若干無理やりな部分も!
(収まり切らなかったとかじゃないよ！)

7. 名前と設計に関する考え
ちょっと名前から外れて、良い設計とはなにか？
● 疎結合が良い
● 高凝集が良い
よく聞く話、なぜか？(というかなに?)

8. 名前と設計
家が一つのパーツでできていたとする

9. 名前と設計
窓が割れたら？

10. 名前と設計
交換が効かない、全部捨てるしかない

11. 名前と設計
逆に必要以上に細かく別れていたら？

12. 名前と設計
求められる性能を発揮できない

13. 名前と設計
ドアに連動して屋根が開いたら？

14. 名前と設計
他の部分も怖くてさわれない

15. 名前と設計
機能性(高凝集) と 独立性(疎結合) が求められる

16. 名前と設計
プログラムも同じ
全部同じクラスやメソッドに書いてしまったら
● 仕様変更となったとき
● 不具合が見つかったとき
● 新しい機能を導入したいとき
適切な粒度で変更できますか？

17. 名前と設計
プログラムも同じ
逆に複数の処理を跨がないと機能を達成できないとしたら
● 修正があったとき全て対応できるか
● 間違った使い方をしないと保証できるか
● 他の処理によって予期せぬ動作を引きおこなさないか
機能性を担保できますか？

18. 名前と設計
適切な境界 ≒ 適切な名前 が必要！

19. 名前と設計
バーガーショップの販売を模した処理を考えてみよう
(Mのつくあのお店)
● 要素をクラス化すればいいよね
● 名詞で名前を付ければいいんでしょ？
○ お店
○ カウンター
○ キッチン
○ お客さん

20. 名前と設計
バーガーショップの販売を模した処理を考えてみよう
(Mのつくあのお店)
● 要素をクラス化すればいいよね
● 名詞で名前を付ければいいんでしょ？
○ お店
○ カウンター
○ キッチン
○ お客さん
本当か？

21. 名前と設計
なんとなくこんな感じかな?
お店
キッチン
カウンター
お客さん

22. 名前と設計
「販売」はどこだ？
お客さん販売
お店
キッチン
カウンター

23. 「販売」ってなんだ？

24. 名前と設計
● 「販売」ってなんでしょうか？
● 名前は知っている
● なんとなくお客さんとお店のやりとりだと思う
● 本当にそうか？
境界線が曖昧(少なくとも、今の自分の中では)

25. 名前と設計
名前「販売」について考える
● メニューを見せる
● 注文を受ける
● 注文をキッチンに伝える
● お金のやり取りを行う
● 商品番号を渡す
● 商品番号に紐づく商品を渡す
「お店」は出て来なかった(お客は隠れているだけかも)

26. 名前と設計
販売
キッチン
番号 商品
注文を受ける 商品を渡す
注文
メニュー
見る

27. 名前と設計
悪くなさそうだけど
販売
キッチン
番号 商品
注文を受ける 商品を渡す
注文
メニュー
見る

28. 名前と設計
名前からの考え方
● 「販売」という名前に自分は戸惑った
○ 他の人はどうだろうか？
● 「販売」という名前は他の機能を持たないだろうか
○ 「商品券」の販売は？
○ メニューの切り替えがあったら？
○ 不要な機能に違和感を示す名前か？

29. より独立した名前を探そう

30. 例えば、こんなの

31. 名前と設計
● メニュー提供
● 注文カウンター
○ 注文を受ける
■ 注文が正しいか確認する
■ 注文をキッチンに伝える
■ お金のやり取りを行う
■ 受け取り番号を発行する
● 提供カウンター
○ 商品の提供
■ 受け取り番号が必要
■ 商品が完成していれば提供する

32. 名前と設計
注文カウンター
キッチン
提供カウンター
注文 番号 商品
メニュー

33. 名前と設計
注文カウンター
キッチン
提供カウンター
注文 番号 商品
メニュー
あれ？「販売」は何処へ・・・

34. 販売
名前と設計
注文カウンター
キッチン
提供カウンター
注文 番号 商品
メニュー
組み合わせて表現
ちょっと怪しい、まだふんわりしてる

35. 名前と設計
注文カウンター
キッチン
提供カウンター
注文 番号 商品
スペシャル
メニュー
変化があっても受け入れられる
A B

36. 名前と設計
● 目につく名前に惑わされない
● 名前(境界)を理解する
○ フォーカスしたい名前の本質を知る
● より小さい概念(の関係性)を見つける
○ カウンターは物理的には1つかもしれない
○ 概念としては「注文」「提供」の二つがある
● 可能なら具体的な名前を付け直す

37. ここから本当に雑談

38. 名前に迷ったとき
● つぶやいてみる
○ 販売は商品を提供する。販売はメニューを変更する。
○ 提供カウンタは商品を提供する。提供カウンタはメニューを変更する。
● となりの人に聞いてみる
○ 2,3人が首を傾げなければ、たぶん大丈夫
○ できれば会話してみると良い
● 英語に迷ったとき
○ 日本語 > 翻訳 > 画像検索
○ 試している最中

39. ハンガリアン記法
● 昔話！！
● Microsoftのチャールズ・シモニイにより考案された
● ハンガリー人らしく、そのままなネーミング
● それが保持するものの種類を示すタグを小文字で付ける

40. ハンガリアン記法
ハンガリアンは二つある
● システムハンガリアン
○ 一般に知られる(知られた)ハンガリアン
○ 暗黒面
● アプリケーションハンガリアン
○ シモニイが本当に提唱したかったもの

41. ハンガリアン記法
● システムハンガリアン
○ 変数の型を表現するタグをつける
○ int なら i, long なら l とかで iCount, lCountとする
○ 型があれば保証してくれる情報じゃない？
○ その変数の型が変更された時に保守が大変
■ 逆に混乱の元になる
○ 推奨されない

42. ハンガリアン記法
● アプリケーションハンガリアン
○ 変数の種類を表現するタグをつける
○ 安全な文字列ならsafeのs、逆ならunsafeのusなど
○ 型では保証できない領域を保証する
○ sPassword = usPassworld 危険なコードが見える
○ 現在は推奨されない(とおもう)

43. ハンガリアン記法
● 現在
○ usというタグの意味を知らないと理解できない
■ 省略の問題が残る
○ us(タグ)よりunsafe(名前)の方が読み手を選ばない
○ 型の力を強化できる
■ strong typedefなどにより強力な型付けが可能
○ 意思は受け継ぎつつ非推奨かなと思う

44. 曖昧な名前
● Get
○ プログラムは、データをやり取りするので至る所に「取得」がある
○ どこから取得したのか? どう取得したのか？
○ 特にインフラレイヤでは気を付けたい(DBとかデバイス付近)
○ メンバのゲッター程度の軽い処理に対して記述されるもイメージ
● Check
○ チェックした後は？あっていればいいのか？間違っていればいいのか？
○ CheckPost(ポストである確認) より AllowPostOnly(ポストのみ許可)
○ CheckBox->Check() チェックマークをつける？(ちょっと無理やり)
● Filter
○ 除外するのか、選ぶのか・・・Selectとかどうですかね。

45. ユビキタス言語
DDDのプラクティスの1つ
開発者とドメインエキスパートとの間で共通の意味を持つ用語を構築する
開発者とドメインエキスパートを含めたチーム全体で作り上げる共通言語
名前に業務上の境界を設け、開発者とドメインエキスパートが会話をし
ドメインへの理解を深め、モデルに反映させる。
共通認識の名前を用いることで、課題に則したモデリングが行える。
バイト経験者と飲食店の例とかをやってみたら面白いかもね！

46. 文化
● 名前は文化から生まれる。
● 勝手に命名ルールを変更するのは文化破壊となる。
● 一人で進むのはやめよう。
● チームで考える(やるべきこと、そうで無いもの)
● 文化がなければ、小さなところから育てよう

47. まとめ

48. まとめ
● プログラムと名前は切っても切れない関係
● 今も昔も色々な考えがある
● 名前の考え方も進化していく
● 読みやすく品質の高いコードを目指しましょう
● 足並みそろえよう

49. 以上、ありがとうございました