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
94
名は体を表していますか
たかが命名、されど命名。名前から考えるよいコード【タガヤス その4】発表資料(2)
https://tagayas.connpass.com/event/80363/
Infiniteloop
October 17, 2023
Tweet
Share
More Decks by Infiniteloop
See All by Infiniteloop
俺の PHP プロファイラの話 PHP スクリプトで PHP 処理系のメモリをのぞき込む
infiniteloop_inc
0
380
心理的安全性を学び直し、 「いい組織とは何か?」を考えてみる
infiniteloop_inc
0
470
ゼロからつくる 2D物理シミュレーション ~物理現象をコードに落とし込む方法~
infiniteloop_inc
1
630
詫び石の裏側
infiniteloop_inc
0
510
[新卒向け研修資料] テスト文字列に「うんこ」と入れるな(2024年版)
infiniteloop_inc
7
29k
リファクタリングで実装が○○分短縮した話
infiniteloop_inc
0
170
ADRという考えを取り入れてみて
infiniteloop_inc
0
170
500万行のPHPプロジェクトにおけるログ出力の歩み
infiniteloop_inc
0
130
I ❤ Virtual Machines 仮想環境をより便利に使うツールたち
infiniteloop_inc
0
110
Other Decks in Programming
See All in Programming
Ça bouge du côté des animations CSS !
goetter
2
150
メンテが命: PHPフレームワークのコンテナ化とアップグレード戦略
shunta27
0
300
新宿駅構内を三人称視点で探索してみる
satoshi7190
2
120
Better Code Design in PHP
afilina
0
170
2025.2.14_Developers Summit 2025_登壇資料
0101unite
0
200
sappoRo.R #12 初心者セッション
kosugitti
0
280
Multi Step Form, Decentralized Autonomous Organization
pumpkiinbell
1
860
Rails 1.0 のコードで学ぶ find_by* と method_missing の仕組み / Learn how find_by_* and method_missing work in Rails 1.0 code
maimux2x
1
210
Djangoにおける複数ユーザー種別認証の設計アプローチ@DjangoCongress JP 2025
delhi09
PRO
4
470
CSS Linter による Baseline サポートの仕組み
ryo_manba
1
150
SwiftUI Viewの責務分離
elmetal
PRO
2
270
dbt Pythonモデルで実現するSnowflake活用術
trsnium
0
260
Featured
See All Featured
Fontdeck: Realign not Redesign
paulrobertlloyd
83
5.4k
Testing 201, or: Great Expectations
jmmastey
42
7.2k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
59k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
33
2.8k
We Have a Design System, Now What?
morganepeng
51
7.4k
Build The Right Thing And Hit Your Dates
maggiecrowley
34
2.5k
Fashionably flexible responsive web design (full day workshop)
malarkey
406
66k
Building a Scalable Design System with Sketch
lauravandoore
461
33k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
226
22k
Why You Should Never Use an ORM
jnunemaker
PRO
55
9.2k
A Modern Web Designer's Workflow
chriscoyier
693
190k
A designer walks into a library…
pauljervisheath
205
24k
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と呼ぶなど
• アーキテクチャによっては役割が決まっている • やりすぎると負担になるので注意
まとめ
まとめ • 名前は体を表さなければならない • 名前は処理境界を作る(そして守る) • 名前は設計の問題をあぶり出す • 名前は違和感を際立たせる •
名前は読み手の負担を減らす
まとめ 自分の「お察し力」は頑張って磨こう 相手に「お察し力」を求めるのはやめよう 名前を考えるだけでだいぶ負担は減る(と思う)
以上、ありがとうございました。