Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

thatblue
January 26, 2019

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

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

thatblue

January 26, 2019
Tweet

More Decks by thatblue

Other Decks in Technology

Transcript

  1. 来月の自分に怒られない
    名前の付け方を考えてみよう
    ……というご提案
    PHPカンファレンス仙台2019
    今野夕貴(@thatblue_plus)

    View full-size slide

  2. (このあとの話題にも繋がるので)
    とりあえず自己紹介
    だいたい仙台出身、ほぼ仙台在住
    学生時代を過ごした会津若松は第二の
    故郷
    新卒から10年くらいソフトウェアエンジ
    ニア的なお仕事をしています
    PHPer歴は通算で7年ちょい
    前職(2012年末〜)くらいからソシャゲや
    スマホゲームのバックエンドを作るお仕事
    をしています
    ここ2〜3年はフレームワーク選定から運用
    まで作る部分はわりと何でもやってる気が
    する
    ガルパン大好きなんですが近くにあんまり
    語り合える人がいないのでお友達になって
    ください

    View full-size slide

  3. 仕事のコードでは名前の付け方について
    褒められることが一番多いので
    今日はその辺の話をしようと思います
    決して他に褒めるところがない、と言う話ではないと信じたいお年頃

    View full-size slide

  4. 過去の自分が書いたコードに対して
    怒りたくなることはありませんか
    当時ベストを尽くしているなら、それ自体は成長の証です
    誇りましょう

    View full-size slide

  5. 経験則として「先週の自分は他人と思え」と
    よく言われますが
    先週の自分にキレるのは大体ロジックがゴチャついているとき
    ※個人の感想です

    View full-size slide

  6. 「なんでこんな名前つけたんだ!」
    ってキレるのは大体先月の自分に対して
    一通り作りきって、文脈に対する理解が深まってるのも大きい

    View full-size slide

  7. プログラムの書き方に関する一般的な注意点については
    「リーダブルコード」という名著があります
    https://www.oreilly.co.jp/books/9784873115658/

    View full-size slide

  8. リーダブルコードでは
    あまり触れられてない(と思う)
    あたりを中心に

    View full-size slide

  9. 来月の自分に怒られないための
    本日のトピック
    呼称が実態と離れがちな問題
    抽象レベルのコントロールが難しい問題
    英語が難しい問題

    View full-size slide

  10. 呼称と実態が離れがちな問題
    ゲーム案件だと特に顕著に感じます

    View full-size slide

  11. 例:スプラトゥーン
    「イカ」を操作して遊ぶゲームであることは
    ご存知の方も多いはず
    Splatoon公式サイトより

    View full-size slide

  12. ゲーム開発中にありがちなこと:
    オブジェクトのモチーフが変わる
    参考:社長が訊く『Splatoon(スプラトゥーン)』
    https://www.nintendo.co.jp/wiiu/interview/agmj/vol1/index.html
    Splatoon公式サイトより

    View full-size slide

  13. モチーフをそのまま名前に
    組み込むと何が起こるのか
    初めに操作キャラクターに関するオブジェクトに
    「Tofu」と付けてしまうと、モチーフ変遷の経緯を
    知らないとコードが読めなくなる
    都度リファクタするのもちょっと勇気がいる
    途中の「ウサギ」のモチーフに依存する命名が混
    ざるともう地獄
    操作キャラクターが「イカ」に確定したあと、別の
    文脈でウサギや豆腐のモチーフが出現するとさらに混
    乱する
    ※私は任天堂関係者ではないので
    あくまで「こういうことが起こるかも」という想像の話です

    View full-size slide

  14. 似たようなことは
    いろんなところで起きている

    View full-size slide

  15. 既に出来上がった版権ベースの
    モチーフなら大丈夫なのでは?
    コンテンツの根幹になるようなモチーフに関しては
    確かにそうなのですが……

    View full-size slide

  16. ベースの世界観があっても
    「絶対」はあんまりない
    「猫アニメのゲーム化で猫の代わりに戦車が出てきたり
    しないよね」という程度の話でしかない
    文脈によってはこれすらありうるのがまた……
    アイテムなど、細かいモチーフが変わることは普通に発
    生する
    コインがチケットになったりなんとか石になったり
    するので、安易に「xxCoin」と付けられない
    逆に、「一旦ボツになったモチーフが別の文脈で再登場
    する」というパターンが起こりがちでもある

    View full-size slide

  17. 対策:そのオブジェクトの
    本質は何なのかを考える
    スプラトゥーンのイカの例なら「Player」等とすれば解決する
    操作キャラクターがタコになっても問題なし!
    そのオブジェクトは何をするものなのか、目的を考える
    目的が違うなら、同じ挙動でも一緒にしてはいけないのが
    難しいところ
    本当は目的が一緒で共通化できるのに、具体的すぎる名前
    に引っ張られて機能を分けないといけなくなる例もありま

    ある程度強引さも必要

    View full-size slide

  18. そして考えをこじらせた
    結果……

    View full-size slide

  19. 抽象レベルのコントロールが
    難しい問題
    抽象度上げすぎると読みづらい、具体的にしすぎると変更に弱い

    View full-size slide

  20. 例:「アプリ内通貨」を
    どう命名するか

    View full-size slide

  21. どうやらこれは
    やりすぎだったらしいケース
    最初の時点ではモチーフが曖昧だったので、そのま
    ま素直に「app currency(アプリ内通貨)」として実
    装した、が……
    多分後でリファクタした(はず)
    この時は悩んでいる間にモチーフが確定したので、
    その名前を使った
    正直、モチーフの具体名以外でこれよりスマートな
    名前をつけろと言われても今のところ良い案は出て
    いません

    View full-size slide

  22. 対策:とことん抽象的に設計して
    とことん具体的に命名する
    既に世の中にあるものをメタファーとして使う
    例えば、世界観に合わせて「召喚」とか「スカウト」という名前で
    あっても、「ゲーム内通貨を消費してリソースの使用権をランダム
    に獲得する機能」は実装上「ガチャ」って呼んでいいと思う
    既存の仕組みやデザインパターンに当てはまるものがあるかもしれな

    有名どころはGoFのデザインパターン
    DDDとか勉強するといいかもしれない
    自分が作ろうとしているアプリケーションに対するそれなりの理解が
    必要
    どうしても端的な表現が出てこない場合、設計がおかしいことも疑って
    みる

    View full-size slide

  23. それを乗り越えた先に
    訪れる……

    View full-size slide

  24. 英語が難しい問題
    つらい

    View full-size slide

  25. 例:EC系サイトで見かけた
    (商品の振る舞いに対して)
    「unsell」という変数名
    un-(否定の接頭辞)+sell(売る)で
    「売れない」としたかったのは分かったのですが……

    View full-size slide

  26. unsellがなぜダメなのか
    「unsell」という英単語は存在しますが、意味は「〔真実性・価値など
    について人に〕信じないように説得する」というもの
    「unsellable」の略、という最大限好意的な解釈をしても「〔商品など
    が〕売れない、買い手がつかない」なので、意味が変わってしまう
    そもそもそういう判断をEC系のサービスで求められることはあま
    りない
    いずれにせよ、「理由がよく分からないけど購入できちゃダメなんだろ
    うな」程度の情報しか得られない
    「購入ボタンを表示させない」という目的で使う変数ならこの情報
    量でも問題ないですが、そもそも単語自体が誤っているのは大問題
    日本語で言うところの「仕様のため休みます」みたいな混乱を招く
    ※英単語の訳はいずれも英辞郎 on the WEBより

    View full-size slide

  27. 代わりになる名前を
    考えてみる
    購入できない: not available

    非売品である: not for sale
    レンタル専用品である: for rental
    出品準備ができていない: not ready
    在庫切れ: out of stock

    View full-size slide

  28. 例2: row(行)とraw(未加工の)と
    low(低い)とlaw(法律)がごっちゃ
    になる問題
    カタカナ英語にすると全部「ロー」

    View full-size slide

  29. もしrawLawRow(未加工の法律の行)
    なんて変数があったら
    正しく覚えられる気がしません……
    IDEの補完機能万歳

    View full-size slide

  30. 対策:とにかく辞書を
    引きましょう
    英語圏の人でも間違えることがある(例:HTTP referer)ので、ノンネイティ
    ブな我々日本人が間違えないワケがないと思って辞書を引く
    英和/和英辞典はスペースアルクの英辞郎 on the WEBがお勧めです
    ProLite(無料)に登録すると用例検索もできます
    同じような単語のニュアンスの違いは用例を見ると分かることが多いで

    専門用語以外はなるべく難易度の低い単語を選ぶのもポイント
    英検2級(高校卒業レベル)前後くらいが目安でしょうか
    これもオンラインの英和辞典を引くと「レベル」として書いてあります
    ローカルなチームであれば、いっそ日本語(ローマ字)で付けてしまうのも手
    私はよく「omake」って付けたりします

    View full-size slide

  31. 使う表現を決める時
    英和/和英辞典以外に
    参照しているもの
    類語辞典(国語・英語ともに)
    英英辞典
    Wikipedia
    日本語ページを表示したあと、「他言語版」のリンクから英語版に飛ぶ
    用例確認にも使えます
    多言語展開しているゲームの攻略Wiki、ニコニコ大百科、ピクシブ百科事典
    など
    Google画像検索
    使いたい表現で検索してイメージ通りの結果が出るかを確認する
    https://qiita.com/jnchito/items/3815a755b889b64a1840 から頂
    いた知恵

    View full-size slide

  32. 国語・英語ともに語彙力を
    試されるなぁって感じることが
    多いです

    View full-size slide

  33. 来月の自分に怒られないための
    本日のまとめ
    呼称が実態と離れがちな問題

    →オブジェクトの本質と目的を考えよう!
    抽象レベルのコントロールが難しい問題

    →とことん抽象的に設計して、とことん具体的
    に命名しよう!
    英語が難しい問題

    →とにかく辞書を引こう!

    View full-size slide

  34. 目指せ、来月の自分に褒められる名付け!

    View full-size slide