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