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
120
名は体を表していますか
たかが命名、されど命名。名前から考えるよいコード【タガヤス その4】発表資料(2)
https://tagayas.connpass.com/event/80363/
Infiniteloop
October 17, 2023
Tweet
Share
More Decks by Infiniteloop
See All by Infiniteloop
[新卒向け研修資料] テスト文字列に「うんこ」と入れるな(2025年版)
infiniteloop_inc
16
60k
俺の PHP プロファイラの話 PHP スクリプトで PHP 処理系のメモリをのぞき込む
infiniteloop_inc
1
560
心理的安全性を学び直し、 「いい組織とは何か?」を考えてみる
infiniteloop_inc
1
800
ゼロからつくる 2D物理シミュレーション ~物理現象をコードに落とし込む方法~
infiniteloop_inc
1
1.2k
詫び石の裏側
infiniteloop_inc
0
780
[新卒向け研修資料] テスト文字列に「うんこ」と入れるな(2024年版)
infiniteloop_inc
7
34k
リファクタリングで実装が○○分短縮した話
infiniteloop_inc
0
240
ADRという考えを取り入れてみて
infiniteloop_inc
0
250
500万行のPHPプロジェクトにおけるログ出力の歩み
infiniteloop_inc
0
180
Other Decks in Programming
See All in Programming
詳しくない分野でのVibe Codingで困ったことと学び/vibe-coding-in-unfamiliar-area
shibayu36
3
5k
Railsだからできる 例外業務に禍根を残さない 設定設計パターン
ei_ei_eiichi
0
910
kiroとCodexで最高のSpec駆動開発を!!数時間で web3ネイティブなミニゲームを作ってみたよ!
mashharuki
0
490
The Past, Present, and Future of Enterprise Java
ivargrimstad
0
380
monorepo の Go テストをはやくした〜い!~最小の依存解決への道のり~ / faster-testing-of-monorepos
convto
2
500
あなたとKaigi on Rails / Kaigi on Rails + You
shimoju
0
160
AI Agent 時代的開發者生存指南
eddie
0
430
Foundation Modelsを実装日本語学習アプリを作ってみた!
hypebeans
0
110
エンジニアインターン「Treasure」とHonoの2年、そして未来へ / Our Journey with Hono Two Years at Treasure and Beyond
carta_engineering
0
130
作って理解するGOCACHEPROG / Go Conference 2025(Workshop)
mazrean
0
100
NixOS + Kubernetesで構築する自宅サーバーのすべて
ichi_h3
0
860
Server Side Kotlin Meetup vol.16: 内部動作を理解して ハイパフォーマンスなサーバサイド Kotlin アプリケーションを書こう
ternbusty
3
190
Featured
See All Featured
Side Projects
sachag
455
43k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
234
17k
The World Runs on Bad Software
bkeepers
PRO
72
11k
Building Better People: How to give real-time feedback that sticks.
wjessup
369
20k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
20
1.2k
Making the Leap to Tech Lead
cromwellryan
135
9.6k
Building Flexible Design Systems
yeseniaperezcruz
329
39k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
115
20k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
31
9.7k
Building a Modern Day E-commerce SEO Strategy
aleyda
44
7.8k
Embracing the Ebb and Flow
colly
88
4.8k
Raft: Consensus for Rubyists
vanstee
140
7.1k
Transcript
名は体を表していますか ~名前から見るコード~
自己紹介 • 名前: ナカノ アキラ • 年齢: 33歳 • 結婚してます。つい先日10周年でした。
• 趣味: お菓子(おやつ)作り
お察し力
お察し力 あなたの近くに優秀なプログラマはいますか?
お察し力 何をもって優秀か • データベースに精通している • 設計に関する知識が高い • オールマイティに全範囲こなせる • ...etc
お察し力 仕様把握や、状況理解の早い人 = 「お察し力」が高い人 というのもあると思います
お察し力 「お察し力」が高い人 チーム内に何人いますか?
お察し力 「お察し力」が高い人に頼る場面 • 既存コードからの仕様把握 • 不可解なバグの解析 • コードレビュー • ...etc
お察し力 「お察し力」が高い人に頼る場面 • 既存コードからの仕様把握 • 不可解なバグの解析 • コードレビュー • ...etc
ある種の属人化!!
お察し力 「お察し力」が求められないコード • 保守性が高い • 属人化の進行が遅い • 引き継ぎコストが安い
お察し力 「お察し力」が求められないコード • 保守性が高い • 属人化の進行が遅い • 引き継ぎコストが安い ◦ プロジェクト価値が高い
◦ 会社に対して明確なメリット
お察し力 どうすればよいか? 簡単なところから始める 「名前の力」 を借りてみるというのはどうか
変数
変数 • 一般に省略は悪とされる ◦ 意味がなくなる ◦ 読み手の負担が増える ◦ 違和感が隠れる
変数 第一にぱっと見わからない • $sd; //skill_damage • $sp; //skill_point • $spd;
//speed 読み手がデコードしなければならない
変数 第一にぱっと見わからない • $sd; //skill_damage • $sp; //skill_point • $spd;
//speed 読み手が記憶しておかなければならない
変数 第一にぱっと見わからない • $sd; //skill_damage • $sp; //skill_point • $spd;
//speed 他の場所ではspがspeedの省略だったりする
変数 違和感に蓋をしない • $w->getName(); • $wood->getName(); 後者は少し気になるコード、木材に名前がある
変数 違和感に蓋をしない • $w->getName(); • $wood->getName(); wでは名前として認識できず意識が向かない
変数 状態をかき混ぜない $not_disable_exclude_filter = false; 読み手どころか、書いた本人もわからないのでは・・・
変数 状態をかき混ぜない $not_disable_exclude_filter = false; ここまでひどいのは、あまりないですが not_disable_hogeぐらいは割と見ます。
変数 • 読み手の負担を考える • 単語の省略はしない • 読み手が欲しい情報を提供する
関数名
関数名 • 一般的に動詞が良いとされる • 名前以上のことをしない • 名前を綺麗につけようとしない • 内部の処理を抽象化して表す
関数名 function giveReward($id){ $reward = fetchRewardMaster($id); storeReward($reward); sendNotification(‘%sを受け取った’, $reward->name()); //
通知 }
関数名 function giveReward($id){ $reward = fetchRewardMaster($id); storeReward($reward); sendNotification(‘%sを受け取った’, $reward->name()); //
通知 } giveRewardは fetchRewardMaster と storeReward を抽象化した名前 sendNotificationが含まれている名前には見えない
関数名 function giveReward($id){ $reward = fetchRewardMaster($id); storeReward($reward); sendNotification(‘%sを受け取った’, $reward->name()); //
通知 } もっと愚直に名前を付けてみよう
関数名 function giveRewardAndNotice($id){ $reward = fetchRewardMaster($id); storeReward($reward); sendNotification(‘%sを受け取った’, $reward->name()); //
通知 } わかりやすい名前をつけるということは、見た目を取り繕うことじゃない やっていること(大事なこと)を書いて読み手に伝えるのは大切だと思う
関数名 function giveRewardAndNotice($id){ $reward = fetchRewardMaster($id); storeReward($reward); sendNotification(‘%sを受け取った’, $reward->name()); //
通知 } さらに、この関数を一言で表す(より抽象化された)名前は無いだろうか? 名前(境界)が存在しないなら、処理の境界も存在しないかもしれない
関数名 これはハンバーガーですね。
関数名 これはなんでしょう
関数名 function giveRewardAndNotice($id, $send_notice){ $reward = fetchMasterReward($id); storeReward($reward); if ($send_notice)
sendNotification(‘%sを受け取った’, $reward->name()); } 処理境界を間違えていると、そのうちこんなコードになる
関数名 • やっていることを書こう • 処理を抽象的に表す名前(境界)を探そう • 名前が無い時は正しいか考えよう ◦ もちろん合っている時もある •
境界は作るものによって変わる ◦ 絶対は存在しない ◦ 途中で変わることもある
関数名 Andが悪いという話じゃないよ • FWやユーティリティなど ◦ それより上の概念が存在しない • 単純に処理を繋げてコード記述量を減らしたい ◦ 複数の処理を一度に呼び出すことが多い
◦ 独立した処理も別にあると良いと思う
クラス名
クラス名 • 一般的に名詞が良いとされる • 可能な限りそれを表す名詞を探す • 曖昧な名前、包括的な名前を使わない ◦ 無意味なManager, Serviceなど
◦ 境界線が曖昧になる ◦ 名前の力が薄れる
クラス名 class NotificationService{ function sendNotification(); } A「メッセージ送信クラスを作ったぞ」 A「送信機能しか持たせていないシンプル イズ ベスト」
A「名前はなんか思いつかなかったしサービスでいいや」
クラス名 class NotificationService{ function sendNotification(); } B「通知サービスクラスか」 < この時点で認識が違う B「通知テキストの管理もここでいいかな」
クラス名 class NotificationService{ function sendNotification(); function addNotificationText(); function removeNotificationText(); }
C「サービス!なんでもできる。いわゆるゴッド!!」 C「受け取り処理もここでいいっしょ」
クラス名 class NotificationService{ function sendNotification(); function addNotificationText(); function removeNotificationText(); function
recieveNotification(); } A「送信クラスだったのに・・・なんでメッセージ管理とか受信処理まで」
広く受ける名前 クラス名 受信機能 送信機能 テキスト コンテナ
広く受ける名前 クラス名 受信機能 送信機能 テキスト コンテナ 大は小を兼ねない
程よい名前 クラス名 受信機能 送信機能 テキスト コンテナ 程よい名前に いい感じの名前
クラス名 class NotificationSender{ function sendNotification(); } A「メッセージ送信クラスはを作ったぞ」 A「送信機能しか持たせていないシンプル イズ ベスト」
A「今度は名前も明示的かつ限定的」
クラス名 class NotificationSender{ function sendNotification(); } B「通知送信クラスか」 B「通知テキストをどこかにまとめたいんだけど、送信者はちょっとなー」 B「NotificationTextContainerとかつくるかー」
クラス名 class NotificationSender{ function sendNotification(); } C「通知の受信処理つくろ!」 C「Senderにrecieve()とか、さすがに違うか」 C「素直にNotificationReceiverつくるか」
クラス名 • 必要以上の意味を持つ名前を付けない ◦ 境界が曖昧になる ◦ 名前の力が薄まる • 適切な境界を持つ名前なら構造を守れる ◦
相手に求めず自己防衛力のある名前を
クラス名 ServiceやManager等は使っちゃダメなのか?
クラス名 ServiceやManager等は使っちゃダメなのか? • 明確な意味を持たない用語 • 自分たちで意味を持たせることができる • ルールを作って使うのはどうか • 例えばファサードをServiceと呼ぶなど
• アーキテクチャによっては役割が決まっている • やりすぎると負担になるので注意
まとめ
まとめ • 名前は体を表さなければならない • 名前は処理境界を作る(そして守る) • 名前は設計の問題をあぶり出す • 名前は違和感を際立たせる •
名前は読み手の負担を減らす
まとめ 自分の「お察し力」は頑張って磨こう 相手に「お察し力」を求めるのはやめよう 名前を考えるだけでだいぶ負担は減る(と思う)
以上、ありがとうございました。