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