たかが命名、されど命名。名前から考えるよいコード【タガヤス その４】発表資料(2) https://tagayas.connpass.com/event/80363/

1. 名は体を表していますか
～名前から見るコード～

2. 自己紹介
● 名前: ナカノ アキラ
● 年齢: 33歳
● 結婚してます。つい先日10周年でした。
● 趣味: お菓子(おやつ)作り

3. お察し力

4. お察し力
あなたの近くに優秀なプログラマはいますか？

5. お察し力
何をもって優秀か
● データベースに精通している
● 設計に関する知識が高い
● オールマイティに全範囲こなせる
● ...etc

6. お察し力
仕様把握や、状況理解の早い人
= 「お察し力」が高い人
というのもあると思います

7. お察し力
「お察し力」が高い人
チーム内に何人いますか？

8. お察し力
「お察し力」が高い人に頼る場面
● 既存コードからの仕様把握
● 不可解なバグの解析
● コードレビュー
● ...etc

9. お察し力
「お察し力」が高い人に頼る場面
● 既存コードからの仕様把握
● 不可解なバグの解析
● コードレビュー
● ...etc
ある種の属人化！！

10. お察し力
「お察し力」が求められないコード
● 保守性が高い
● 属人化の進行が遅い
● 引き継ぎコストが安い

11. お察し力
「お察し力」が求められないコード
● 保守性が高い
● 属人化の進行が遅い
● 引き継ぎコストが安い
○ プロジェクト価値が高い
○ 会社に対して明確なメリット

12. お察し力
どうすればよいか？
簡単なところから始める
「名前の力」
を借りてみるというのはどうか

13. 変数

14. 変数
● 一般に省略は悪とされる
○ 意味がなくなる
○ 読み手の負担が増える
○ 違和感が隠れる

15. 変数
第一にぱっと見わからない
● $sd; //skill_damage
● $sp; //skill_point
● $spd; //speed
読み手がデコードしなければならない

16. 変数
第一にぱっと見わからない
● $sd; //skill_damage
● $sp; //skill_point
● $spd; //speed
読み手が記憶しておかなければならない

17. 変数
第一にぱっと見わからない
● $sd; //skill_damage
● $sp; //skill_point
● $spd; //speed
他の場所ではspがspeedの省略だったりする

18. 変数
違和感に蓋をしない
● $w->getName();
● $wood->getName();
後者は少し気になるコード、木材に名前がある

19. 変数
違和感に蓋をしない
● $w->getName();
● $wood->getName();
wでは名前として認識できず意識が向かない

20. 変数
状態をかき混ぜない
$not_disable_exclude_filter = false;
読み手どころか、書いた本人もわからないのでは・・・

21. 変数
状態をかき混ぜない
$not_disable_exclude_filter = false;
ここまでひどいのは、あまりないですが
not_disable_hogeぐらいは割と見ます。

22. 変数
● 読み手の負担を考える
● 単語の省略はしない
● 読み手が欲しい情報を提供する

23. 関数名

24. 関数名
● 一般的に動詞が良いとされる
● 名前以上のことをしない
● 名前を綺麗につけようとしない
● 内部の処理を抽象化して表す

25. 関数名
function giveReward($id){
$reward = fetchRewardMaster($id);
storeReward($reward);
sendNotification(‘%sを受け取った’, $reward->name()); // 通知
}

26. 関数名
function giveReward($id){
$reward = fetchRewardMaster($id);
storeReward($reward);
sendNotification(‘%sを受け取った’, $reward->name()); // 通知
}
giveRewardは fetchRewardMaster と storeReward を抽象化した名前
sendNotificationが含まれている名前には見えない

27. 関数名
function giveReward($id){
$reward = fetchRewardMaster($id);
storeReward($reward);
sendNotification(‘%sを受け取った’, $reward->name()); // 通知
}
もっと愚直に名前を付けてみよう

28. 関数名
function giveRewardAndNotice($id){
$reward = fetchRewardMaster($id);
storeReward($reward);
sendNotification(‘%sを受け取った’, $reward->name()); // 通知
}
わかりやすい名前をつけるということは、見た目を取り繕うことじゃない
やっていること(大事なこと)を書いて読み手に伝えるのは大切だと思う

29. 関数名
function giveRewardAndNotice($id){
$reward = fetchRewardMaster($id);
storeReward($reward);
sendNotification(‘%sを受け取った’, $reward->name()); // 通知
}
さらに、この関数を一言で表す(より抽象化された)名前は無いだろうか？
名前(境界)が存在しないなら、処理の境界も存在しないかもしれない

30. 関数名
これはハンバーガーですね。

31. 関数名
これはなんでしょう

32. 関数名
function giveRewardAndNotice($id, $send_notice){
$reward = fetchMasterReward($id);
storeReward($reward);
if ($send_notice) sendNotification(‘%sを受け取った’, $reward->name());
}
処理境界を間違えていると、そのうちこんなコードになる

33. 関数名
● やっていることを書こう
● 処理を抽象的に表す名前(境界)を探そう
● 名前が無い時は正しいか考えよう
○ もちろん合っている時もある
● 境界は作るものによって変わる
○ 絶対は存在しない
○ 途中で変わることもある

34. 関数名
Andが悪いという話じゃないよ
● FWやユーティリティなど
○ それより上の概念が存在しない
● 単純に処理を繋げてコード記述量を減らしたい
○ 複数の処理を一度に呼び出すことが多い
○ 独立した処理も別にあると良いと思う

35. クラス名

36. クラス名
● 一般的に名詞が良いとされる
● 可能な限りそれを表す名詞を探す
● 曖昧な名前、包括的な名前を使わない
○ 無意味なManager, Serviceなど
○ 境界線が曖昧になる
○ 名前の力が薄れる

37. クラス名
class NotificationService{
function sendNotification();
}
A「メッセージ送信クラスを作ったぞ」
A「送信機能しか持たせていないシンプル イズ ベスト」
A「名前はなんか思いつかなかったしサービスでいいや」

38. クラス名
class NotificationService{
function sendNotification();
}
B「通知サービスクラスか」 < この時点で認識が違う
B「通知テキストの管理もここでいいかな」

39. クラス名
class NotificationService{
function sendNotification();
function addNotificationText();
function removeNotificationText();
}
C「サービス！なんでもできる。いわゆるゴッド！！」
C「受け取り処理もここでいいっしょ」

40. クラス名
class NotificationService{
function sendNotification();
function addNotificationText();
function removeNotificationText();
function recieveNotification();
}
A「送信クラスだったのに・・・なんでメッセージ管理とか受信処理まで」

41. 広く受ける名前
クラス名
受信機能
送信機能
テキスト
コンテナ

42. 広く受ける名前
クラス名
受信機能
送信機能
テキスト
コンテナ
大は小を兼ねない

43. 程よい名前
クラス名
受信機能
送信機能
テキスト
コンテナ
程よい名前に
いい感じの名前

44. クラス名
class NotificationSender{
function sendNotification();
}
A「メッセージ送信クラスはを作ったぞ」
A「送信機能しか持たせていないシンプル イズ ベスト」
A「今度は名前も明示的かつ限定的」

45. クラス名
class NotificationSender{
function sendNotification();
}
B「通知送信クラスか」
B「通知テキストをどこかにまとめたいんだけど、送信者はちょっとなー」
B「NotificationTextContainerとかつくるかー」

46. クラス名
class NotificationSender{
function sendNotification();
}
C「通知の受信処理つくろ！」
C「Senderにrecieve()とか、さすがに違うか」
C「素直にNotificationReceiverつくるか」

47. クラス名
● 必要以上の意味を持つ名前を付けない
○ 境界が曖昧になる
○ 名前の力が薄まる
● 適切な境界を持つ名前なら構造を守れる
○ 相手に求めず自己防衛力のある名前を

48. クラス名
ServiceやManager等は使っちゃダメなのか?

49. クラス名
ServiceやManager等は使っちゃダメなのか?
● 明確な意味を持たない用語
● 自分たちで意味を持たせることができる
● ルールを作って使うのはどうか
● 例えばファサードをServiceと呼ぶなど
● アーキテクチャによっては役割が決まっている
● やりすぎると負担になるので注意

50. まとめ

51. まとめ
● 名前は体を表さなければならない
● 名前は処理境界を作る(そして守る)
● 名前は設計の問題をあぶり出す
● 名前は違和感を際立たせる
● 名前は読み手の負担を減らす

52. まとめ
自分の「お察し力」は頑張って磨こう
相手に「お察し力」を求めるのはやめよう
名前を考えるだけでだいぶ負担は減る(と思う)

53. 以上、ありがとうございました。