来月の自分に怒られない名前の付け方を考えてみよう / better naming on programming

PHPカンファレンス仙台(ぺちコン仙台)2019 セッション発表資料

Transcript

1. 来月の自分に怒られない 名前の付け方を考えてみよう ……というご提案 PHPカンファレンス仙台2019 今野夕貴(@thatblue_plus)
2. (このあとの話題にも繋がるので) とりあえず自己紹介 だいたい仙台出身、ほぼ仙台在住 学生時代を過ごした会津若松は第二の 故郷 新卒から10年くらいソフトウェアエンジ ニア的なお仕事をしています PHPer歴は通算で7年ちょい 前職(2012年末〜)くらいからソシャゲや スマホゲームのバックエンドを作るお仕事 をしています ここ2〜3年はフレームワーク選定から運用 まで作る部分はわりと何でもやってる気が する ガルパン大好きなんですが近くにあんまり 語り合える人がいないのでお友達になって ください
3. 仕事のコードでは名前の付け方について 褒められることが一番多いので 今日はその辺の話をしようと思います 決して他に褒めるところがない、と言う話ではないと信じたいお年頃
4. 過去の自分が書いたコードに対して 怒りたくなることはありませんか 当時ベストを尽くしているなら、それ自体は成長の証です 誇りましょう
5. 経験則として「先週の自分は他人と思え」と よく言われますが 先週の自分にキレるのは大体ロジックがゴチャついているとき ※個人の感想です
6. 「なんでこんな名前つけたんだ！」 ってキレるのは大体先月の自分に対して 一通り作りきって、文脈に対する理解が深まってるのも大きい
7. プログラムの書き方に関する一般的な注意点については 「リーダブルコード」という名著があります https://www.oreilly.co.jp/books/9784873115658/
8. リーダブルコードでは あまり触れられてない(と思う) あたりを中心に
9. 来月の自分に怒られないための 本日のトピック 呼称が実態と離れがちな問題 抽象レベルのコントロールが難しい問題 英語が難しい問題
10. 呼称と実態が離れがちな問題 ゲーム案件だと特に顕著に感じます
11. 例:スプラトゥーン 「イカ」を操作して遊ぶゲームであることは ご存知の方も多いはず Splatoon公式サイトより
12. ゲーム開発中にありがちなこと: オブジェクトのモチーフが変わる 参考:社長が訊く『Splatoon（スプラトゥーン）』 https://www.nintendo.co.jp/wiiu/interview/agmj/vol1/index.html Splatoon公式サイトより
13. モチーフをそのまま名前に 組み込むと何が起こるのか 初めに操作キャラクターに関するオブジェクトに 「Tofu」と付けてしまうと、モチーフ変遷の経緯を 知らないとコードが読めなくなる 都度リファクタするのもちょっと勇気がいる 途中の「ウサギ」のモチーフに依存する命名が混 ざるともう地獄 操作キャラクターが「イカ」に確定したあと、別の 文脈でウサギや豆腐のモチーフが出現するとさらに混 乱する ※私は任天堂関係者ではないので あくまで「こういうことが起こるかも」という想像の話です
14. 似たようなことは いろんなところで起きている
15. 既に出来上がった版権ベースの モチーフなら大丈夫なのでは？ コンテンツの根幹になるようなモチーフに関しては 確かにそうなのですが……
16. ベースの世界観があっても 「絶対」はあんまりない 「猫アニメのゲーム化で猫の代わりに戦車が出てきたり しないよね」という程度の話でしかない 文脈によってはこれすらありうるのがまた…… アイテムなど、細かいモチーフが変わることは普通に発 生する コインがチケットになったりなんとか石になったり するので、安易に「xxCoin」と付けられない 逆に、「一旦ボツになったモチーフが別の文脈で再登場 する」というパターンが起こりがちでもある
17. 対策:そのオブジェクトの 本質は何なのかを考える スプラトゥーンのイカの例なら「Player」等とすれば解決する 操作キャラクターがタコになっても問題なし！ そのオブジェクトは何をするものなのか、目的を考える 目的が違うなら、同じ挙動でも一緒にしてはいけないのが 難しいところ 本当は目的が一緒で共通化できるのに、具体的すぎる名前 に引っ張られて機能を分けないといけなくなる例もありま す ある程度強引さも必要
18. そして考えをこじらせた 結果……
19. 抽象レベルのコントロールが 難しい問題 抽象度上げすぎると読みづらい、具体的にしすぎると変更に弱い
20. 例:「アプリ内通貨」を どう命名するか
21. どうやらこれは やりすぎだったらしいケース 最初の時点ではモチーフが曖昧だったので、そのま ま素直に「app currency(アプリ内通貨)」として実 装した、が…… 多分後でリファクタした(はず) この時は悩んでいる間にモチーフが確定したので、 その名前を使った 正直、モチーフの具体名以外でこれよりスマートな 名前をつけろと言われても今のところ良い案は出て いません
22. 対策:とことん抽象的に設計して とことん具体的に命名する 既に世の中にあるものをメタファーとして使う 例えば、世界観に合わせて「召喚」とか「スカウト」という名前で あっても、「ゲーム内通貨を消費してリソースの使用権をランダム に獲得する機能」は実装上「ガチャ」って呼んでいいと思う 既存の仕組みやデザインパターンに当てはまるものがあるかもしれな い 有名どころはGoFのデザインパターン DDDとか勉強するといいかもしれない 自分が作ろうとしているアプリケーションに対するそれなりの理解が 必要 どうしても端的な表現が出てこない場合、設計がおかしいことも疑って みる
23. それを乗り越えた先に 訪れる……
24. 英語が難しい問題 つらい
25. 例:EC系サイトで見かけた (商品の振る舞いに対して) 「unsell」という変数名 un-(否定の接頭辞)+sell(売る)で 「売れない」としたかったのは分かったのですが……
26. unsellがなぜダメなのか 「unsell」という英単語は存在しますが、意味は「〔真実性・価値など について人に〕信じないように説得する」というもの 「unsellable」の略、という最大限好意的な解釈をしても「〔商品など が〕売れない、買い手がつかない」なので、意味が変わってしまう そもそもそういう判断をEC系のサービスで求められることはあま りない いずれにせよ、「理由がよく分からないけど購入できちゃダメなんだろ うな」程度の情報しか得られない 「購入ボタンを表示させない」という目的で使う変数ならこの情報 量でも問題ないですが、そもそも単語自体が誤っているのは大問題 日本語で言うところの「仕様のため休みます」みたいな混乱を招く ※英単語の訳はいずれも英辞郎 on the WEBより
27. 代わりになる名前を 考えてみる 購入できない: not available
 非売品である: not for sale レンタル専用品である: for rental 出品準備ができていない: not ready 在庫切れ: out of stock
28. 例2: row(行)とraw(未加工の)と low(低い)とlaw(法律)がごっちゃ になる問題 カタカナ英語にすると全部「ロー」
29. もしrawLawRow(未加工の法律の行) なんて変数があったら 正しく覚えられる気がしません…… IDEの補完機能万歳
30. 対策:とにかく辞書を 引きましょう 英語圏の人でも間違えることがある(例:HTTP referer)ので、ノンネイティ ブな我々日本人が間違えないワケがないと思って辞書を引く 英和/和英辞典はスペースアルクの英辞郎 on the WEBがお勧めです ProLite(無料)に登録すると用例検索もできます 同じような単語のニュアンスの違いは用例を見ると分かることが多いで す 専門用語以外はなるべく難易度の低い単語を選ぶのもポイント 英検2級(高校卒業レベル)前後くらいが目安でしょうか これもオンラインの英和辞典を引くと「レベル」として書いてあります ローカルなチームであれば、いっそ日本語(ローマ字)で付けてしまうのも手 私はよく「omake」って付けたりします
31. 使う表現を決める時 英和/和英辞典以外に 参照しているもの 類語辞典(国語・英語ともに) 英英辞典 Wikipedia 日本語ページを表示したあと、「他言語版」のリンクから英語版に飛ぶ 用例確認にも使えます 多言語展開しているゲームの攻略Wiki、ニコニコ大百科、ピクシブ百科事典 など Google画像検索 使いたい表現で検索してイメージ通りの結果が出るかを確認する https://qiita.com/jnchito/items/3815a755b889b64a1840 から頂 いた知恵
32. 国語・英語ともに語彙力を 試されるなぁって感じることが 多いです
33. 来月の自分に怒られないための 本日のまとめ 呼称が実態と離れがちな問題
 →オブジェクトの本質と目的を考えよう！ 抽象レベルのコントロールが難しい問題
 →とことん抽象的に設計して、とことん具体的 に命名しよう！ 英語が難しい問題
 →とにかく辞書を引こう！
34. 目指せ、来月の自分に褒められる名付け！