たかが命名、されど命名

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. 思いやりをもった命名を！