Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
プログラムと名前にまつわる座談会
Search
Infiniteloop
October 17, 2023
Programming
0
46
プログラムと名前にまつわる座談会
たかが命名、されど命名。名前から考えるよいコード【タガヤス その4】発表資料(3)
https://tagayas.connpass.com/event/80363/
Infiniteloop
October 17, 2023
Tweet
Share
More Decks by Infiniteloop
See All by Infiniteloop
詫び石の裏側
infiniteloop_inc
0
130
[新卒向け研修資料] テスト文字列に「うんこ」と入れるな(2024年版)
infiniteloop_inc
5
19k
リファクタリングで実装が○○分短縮した話
infiniteloop_inc
0
66
ADRという考えを取り入れてみて
infiniteloop_inc
0
57
500万行のPHPプロジェクトにおけるログ出力の歩み
infiniteloop_inc
0
74
I ❤ Virtual Machines 仮想環境をより便利に使うツールたち
infiniteloop_inc
0
40
アニメーションとスキニングをBurstで独自実装する
infiniteloop_inc
0
110
VRChatでお酒が注げる飲み物アセットの紹介
infiniteloop_inc
0
94
3Dプリンタって いいね
infiniteloop_inc
0
32
Other Decks in Programming
See All in Programming
スタックトレース始めてみた
kuro_kurorrr
4
1.1k
RaaP
ksss
0
160
TypeScript 関数型スタイルでバックエンド開発のリアル
naoya
49
16k
Enjoy Creative Coding with Ruby (RubyKaigi2024)
chobishiba
0
100
Long journey of Ruby standard library RubyKaigi 2024
andpad
2
210
Embedding it into Ruby code
soutaro
1
310
Escolhendo (ou não) o melhor ORM para o seu projeto
andreiacsilva
1
160
Open AI APIを使う前に知っておきたいアカウントTier の話
akki_megane
0
130
freeeのエンジニアが 就活で出そうな コーディングテストを 解説してみる
freee
1
160
HonoのRPCで真の型安全が欲しかった
kosei28
0
110
チーム立ち上げにAWSを活用したらClaudeさんに褒められた話
mkdev10
3
230
Adding Security to Microcontroller Ruby
sylph01
1
160
Featured
See All Featured
GraphQLとの向き合い方2022年版
quramy
33
13k
Robots, Beer and Maslow
schacon
PRO
155
8k
Building a Modern Day E-commerce SEO Strategy
aleyda
22
6.5k
Rails Girls Zürich Keynote
gr2m
91
13k
5 minutes of I Can Smell Your CMS
philhawksworth
199
19k
Product Roadmaps are Hard
iamctodd
45
9.8k
Building Better People: How to give real-time feedback that sticks.
wjessup
356
18k
Done Done
chrislema
178
15k
A designer walks into a library…
pauljervisheath
201
23k
Into the Great Unknown - MozCon
thekraken
15
1.1k
The Invisible Side of Design
smashingmag
294
49k
Practical Orchestrator
shlominoach
183
9.8k
Transcript
プログラムと 名前にまつわる 雑談会
自己紹介 • 名前: Akira Nakano • 趣味: ボビンレース(はじめたばかり)
雑談会 プログラムと名前に関係するお話をつらつらと
名前と設計に関する考え (自分の)
名前と設計に関する考え 「雑談」で話す理由 • 設計って一つの視点で行うものじゃない • ユーザー, 開発者, フレームワーク, 実行環境, etc…
• 同じ題材でも求められるものが違う ◦ 実在するお店のシステム ◦ ゲーム内の武器屋
名前と設計に関する考え 「雑談」で話す理由 名前のみでは語れない、でも名前を考えることは大切 なので、若干無理やりな部分も! (収まり切らなかったとかじゃないよ!)
名前と設計に関する考え ちょっと名前から外れて、良い設計とはなにか? • 疎結合が良い • 高凝集が良い よく聞く話、なぜか?(というかなに?)
名前と設計 家が一つのパーツでできていたとする
名前と設計 窓が割れたら?
名前と設計 交換が効かない、全部捨てるしかない
名前と設計 逆に必要以上に細かく別れていたら?
名前と設計 求められる性能を発揮できない
名前と設計 ドアに連動して屋根が開いたら?
名前と設計 他の部分も怖くてさわれない
名前と設計 機能性(高凝集) と 独立性(疎結合) が求められる
名前と設計 プログラムも同じ 全部同じクラスやメソッドに書いてしまったら • 仕様変更となったとき • 不具合が見つかったとき • 新しい機能を導入したいとき 適切な粒度で変更できますか?
名前と設計 プログラムも同じ 逆に複数の処理を跨がないと機能を達成できないとしたら • 修正があったとき全て対応できるか • 間違った使い方をしないと保証できるか • 他の処理によって予期せぬ動作を引きおこなさないか 機能性を担保できますか?
名前と設計 適切な境界 ≒ 適切な名前 が必要!
名前と設計 バーガーショップの販売を模した処理を考えてみよう (Mのつくあのお店) • 要素をクラス化すればいいよね • 名詞で名前を付ければいいんでしょ? ◦ お店 ◦
カウンター ◦ キッチン ◦ お客さん
名前と設計 バーガーショップの販売を模した処理を考えてみよう (Mのつくあのお店) • 要素をクラス化すればいいよね • 名詞で名前を付ければいいんでしょ? ◦ お店 ◦
カウンター ◦ キッチン ◦ お客さん 本当か?
名前と設計 なんとなくこんな感じかな? お店 キッチン カウンター お客さん
名前と設計 「販売」はどこだ? お客さん 販売 お店 キッチン カウンター
「販売」ってなんだ?
名前と設計 • 「販売」ってなんでしょうか? • 名前は知っている • なんとなくお客さんとお店のやりとりだと思う • 本当にそうか? 境界線が曖昧(少なくとも、今の自分の中では)
名前と設計 名前「販売」について考える • メニューを見せる • 注文を受ける • 注文をキッチンに伝える • お金のやり取りを行う
• 商品番号を渡す • 商品番号に紐づく商品を渡す 「お店」は出て来なかった(お客は隠れているだけかも)
名前と設計 販売 キッチン 番号 商品 注文を受ける 商品を渡す 注文 メニュー 見る
名前と設計 悪くなさそうだけど 販売 キッチン 番号 商品 注文を受ける 商品を渡す 注文 メニュー
見る
名前と設計 名前からの考え方 • 「販売」という名前に自分は戸惑った ◦ 他の人はどうだろうか? • 「販売」という名前は他の機能を持たないだろうか ◦ 「商品券」の販売は?
◦ メニューの切り替えがあったら? ◦ 不要な機能に違和感を示す名前か?
より独立した名前を探そう
例えば、こんなの
名前と設計 • メニュー提供 • 注文カウンター ◦ 注文を受ける ▪ 注文が正しいか確認する ▪
注文をキッチンに伝える ▪ お金のやり取りを行う ▪ 受け取り番号を発行する • 提供カウンター ◦ 商品の提供 ▪ 受け取り番号が必要 ▪ 商品が完成していれば提供する
名前と設計 注文カウンター キッチン 提供カウンター 注文 番号 商品 メニュー
名前と設計 注文カウンター キッチン 提供カウンター 注文 番号 商品 メニュー あれ?「販売」は何処へ・・・
販売 名前と設計 注文カウンター キッチン 提供カウンター 注文 番号 商品 メニュー 組み合わせて表現
ちょっと怪しい、まだふんわりしてる
名前と設計 注文カウンター キッチン 提供カウンター 注文 番号 商品 スペシャル メニュー 変化があっても受け入れられる
A B
名前と設計 • 目につく名前に惑わされない • 名前(境界)を理解する ◦ フォーカスしたい名前の本質を知る • より小さい概念(の関係性)を見つける ◦
カウンターは物理的には1つかもしれない ◦ 概念としては「注文」「提供」の二つがある • 可能なら具体的な名前を付け直す
ここから本当に雑談
名前に迷ったとき • つぶやいてみる ◦ 販売は商品を提供する。販売はメニューを変更する。 ◦ 提供カウンタは商品を提供する。提供カウンタはメニューを変更する。 • となりの人に聞いてみる ◦
2,3人が首を傾げなければ、たぶん大丈夫 ◦ できれば会話してみると良い • 英語に迷ったとき ◦ 日本語 > 翻訳 > 画像検索 ◦ 試している最中
ハンガリアン記法 • 昔話!! • Microsoftのチャールズ・シモニイにより考案された • ハンガリー人らしく、そのままなネーミング • それが保持するものの種類を示すタグを小文字で付ける
ハンガリアン記法 ハンガリアンは二つある • システムハンガリアン ◦ 一般に知られる(知られた)ハンガリアン ◦ 暗黒面 • アプリケーションハンガリアン
◦ シモニイが本当に提唱したかったもの
ハンガリアン記法 • システムハンガリアン ◦ 変数の型を表現するタグをつける ◦ int なら i, long
なら l とかで iCount, lCountとする ◦ 型があれば保証してくれる情報じゃない? ◦ その変数の型が変更された時に保守が大変 ▪ 逆に混乱の元になる ◦ 推奨されない
ハンガリアン記法 • アプリケーションハンガリアン ◦ 変数の種類を表現するタグをつける ◦ 安全な文字列ならsafeのs、逆ならunsafeのusなど ◦ 型では保証できない領域を保証する ◦
sPassword = usPassworld 危険なコードが見える ◦ 現在は推奨されない(とおもう)
ハンガリアン記法 • 現在 ◦ usというタグの意味を知らないと理解できない ▪ 省略の問題が残る ◦ us(タグ)よりunsafe(名前)の方が読み手を選ばない ◦
型の力を強化できる ▪ strong typedefなどにより強力な型付けが可能 ◦ 意思は受け継ぎつつ非推奨かなと思う
曖昧な名前 • Get ◦ プログラムは、データをやり取りするので至る所に「取得」がある ◦ どこから取得したのか? どう取得したのか? ◦ 特にインフラレイヤでは気を付けたい(DBとかデバイス付近)
◦ メンバのゲッター程度の軽い処理に対して記述されるもイメージ • Check ◦ チェックした後は?あっていればいいのか?間違っていればいいのか? ◦ CheckPost(ポストである確認) より AllowPostOnly(ポストのみ許可) ◦ CheckBox->Check() チェックマークをつける?(ちょっと無理やり) • Filter ◦ 除外するのか、選ぶのか・・・Selectとかどうですかね。
ユビキタス言語 DDDのプラクティスの1つ 開発者とドメインエキスパートとの間で共通の意味を持つ用語を構築する 開発者とドメインエキスパートを含めたチーム全体で作り上げる共通言語 名前に業務上の境界を設け、開発者とドメインエキスパートが会話をし ドメインへの理解を深め、モデルに反映させる。 共通認識の名前を用いることで、課題に則したモデリングが行える。 バイト経験者と飲食店の例とかをやってみたら面白いかもね!
文化 • 名前は文化から生まれる。 • 勝手に命名ルールを変更するのは文化破壊となる。 • 一人で進むのはやめよう。 • チームで考える(やるべきこと、そうで無いもの) •
文化がなければ、小さなところから育てよう
まとめ
まとめ • プログラムと名前は切っても切れない関係 • 今も昔も色々な考えがある • 名前の考え方も進化していく • 読みやすく品質の高いコードを目指しましょう •
足並みそろえよう
以上、ありがとうございました