たかが命名、されど命名

Transcript

1. たかが命名、されど命名 思いやりのある命名をしよう
2. DDDとの関わり • 専門学校 3年生 「エリック・エヴァンスのドメイン駆動設計 」を読む => 分からなくて読むの諦める • 専門学校 4年生 「実践ドメイン駆動設計」を読む => なんとなく分か… 分からなくて読むの諦める
3. 命名にどれだけ時間を 使ってますか？
4. プログラミングにおける命名 • クラス名 • メソッド名 • 変数名（ローカル・フィールド）
5. 命名をこだわらなくても動く
6. なぜ、名前をつけるのか？ 自分の書いたコードを理解できるようにする為
7. その時の自分だけがわかる 命名になりがち
8. なぜ、名前をつけるのか？ 自分の書いたコードを他の人(未来の自分も含む)にも理解できる ようにする為
9. 理解が出来ないことで起こること • 全貌の把握に時間がかかる・把握出来ない • 変更・削除していいものか判断がつかない • 機能追加・変更に臆病になってしまう
10. サービスの成長が遅くなる
11. そうならないように 良い命名をしよう！
12. 良い命名とは？ 仕様のどの部分を表現しているのかがわかりやすい事 • 探しやすい => パッケージ構成など • 理解がしやすい ◦ 名前が責務を表す ◦ 単語が仕様書に出てくる単語である
13. 良い命名とは？ 仕様のどの部分を表現しているのかがわかりやすい事 • 探しやすい => パッケージ構成など • 理解がしやすい ◦ 名前が責務を表す ◦ 単語が仕様書に出てくる単語である
14. 良い命名が出来ない？ • 仕様がちゃんと理解出来ていない・詳細に定義されていない • 単語で命名しようとしている 一度やりたいことを文章に書き出して整理しよう • クラスやメソッドが色んな事をしようとしている (多重責務)
15. 全てを説明しようと思い 長い名前になってしまう
16. 長い名前になってしまった時は？ • 多重責務になってないか改めて考え、責務を分割しよう • 単語を省略する(おすすめしません) 省略する時は、ルールを決める
17. 省略するのではなくスコープを切る 適切にスコープを切ることで、長い名前を短くする => 〇〇▲▲☆☆を〇〇の▲▲の☆☆にする • インナークラス ResultListItem => ResultList.Item • クラスのフィールドにする userName => user.name
18. 名前を考える
19. 良い命名をする為の準備 • プログラミングでよく使われるパターン(デザインパターンなど) を覚えよう BuilderやFactory、Dao、Dto • 文法をチームで決めておく 例) メソッド名は 動詞 + 名詞 など • チーム内での単語帳を作っておく
20. つけちゃ駄目な名前 • 〇〇Manager => 〇〇を管理するクラス • 〇〇Util => 〇〇を扱う便利メソッドが詰められたクラス 上の名前をつけたくなったらHOWを考えて分解しよう • 〇〇をどう管理するのか？ • 〇〇をどうやって便利にするのか？
21. 良い名前かどうかを判断する方法 • 他の人にコードを呼んでもらう ◦ レビュー ◦ 時間をおいてセルフレビュー
22. 命名だけでは伝えきれない 他の人に伝える方法 • 命名 • コメント • ドキュメント
23. 伝えられる情報量 命名 コメント ドキュメント 少ない 多い
24. コメントやドキュメントの方が良いのでは？
25. 伝え方とコードとの距離 命名 コメント ドキュメント 近い 遠い
26. コードとの距離が遠くなれば、情報の鮮度が落ちる コードを修正した時に情報の更新を忘れられ、コードと情報に差 異が生まれる。 コメントとコードで言っていること・やっていることが違うという事態 に
27. いつ、だれに、どれだけ伝えたいかで 伝え方を選択しよう
28. まとめ • 良い命名をするのは簡単ではないが、適当な命名をすると後 悔するかも？ • 命名だけでは全てを伝えられない、伝える方法にはメリット・デ メリットがある • 良い命名が出来るようになるには、日々訓練するしかない
29. 思いやりをもった命名を！