プログラムを書いていると命名に迷うことはよくある。クラス名、メソッド名、変数名、パッケージ名などなど。
メソッドは動詞で始めようとかbooleanの変数はisで始めるとかそういう小手先の規則ももちろん大事だけども、命名に迷っているときに足りないのは作っているシステムや業務への理解だと思っている。
名は体を表す、というか名に体を表させるというか。
例としてはミノ駆動氏のクソコード動画「Userクラス」がとても分かりやすい。
そのシステム、業務における「User」というものへの理解が足りないときにクソコードが生まれるという話。
「User」とはなんなのか、似たような概念に何があるのか、「User」にバリエーションはあるのかなどなど、そういうことを考える癖をつけておくとよい。
コードレビューなんかで「User」のような意味の大きい、漠然とした命名のものが出てきた時に匂いがわかるようになる。
自分でコードを書く時も「この変数はこういうものを保存しています」とか「このメソッドはこういうことをしています」というのがちゃんと理解できていれば漠然とした名前にはならないと思う。
DDDはそのあたりを解決するための手法なんだと理解している。
値オブジェクトやらエンティティやらはあくまで理解した業務をどうコードに落とし込むかのHOWであって、本当に目指すところはモデリングを通して業務を理解し、それを言葉に落とすことなんじゃないかなと。
ということで、私はコードを書いていたり設計をしているときに命名に迷ったら、実装しようとしている業務やシステムのことを理解しているかを自問自答するようにしている。
