的確な命名はコストダウンにつながる
なんか結論をタイトルに書いただけですべて言い尽くしてしまった感があるんだけど、一応書く。
設計の質が向上する
設計時点でクラスの責務とかメソッドの処理内容などを検討するとか、レビューなんかでも議論されるんだろう。そのときに同時に、クラスやメソッドの命名が的確になされているかをチェックすべきだ。
クラス名が的確ならばクラス名を見ただけで、そのクラスの責務が推測できる。これはとても重要なことで、例えば何かの機能追加をしようとしたときに、そのクラスに実装を追加すべきなのか、それとも別のクラスに追加すべきなのか(または新たなクラスを作成すべきなのか)、判断の拠り所にもなりうる。
メソッド名が的確ならば、メソッド名が意味している以上の処理を書こうとすると不自然になるので、自然とatomicなメソッドになりやすい。もちろん、気付かなかったらatomicにならないんだけど、ぼんやりしたメソッド名だった場合に比べると、明らかに気付きやすいし、結果的にatomicになりやすいはず。
つまり、クラスやメソッドを的確に命名することは、クラスやメソッドの仕様を明確にするという役割を持っているのだ。
逆に、クラス名やメソッド名を見ても、それがなんなのかピンとこないような場合はどうするかというと、クラスやメソッドを理解するためにドキュメントやコードを読まなければならない。
的確に命名されていても英語の意味が分からん！とかいう場合もあるかもしれんけど、そういうときは辞書引いて意味を調べ、コードを読んで確認すればよい。辞書を何度か引けば、いつかは単語の意味を覚える。しかし、命名が不適切な場合は、名が体を表してないので、毎回コードを読むハメになる。
命名はイニシャルコストだ
命名のためには適切な単語を選ばないといけないので、当然、辞書を引くことも必要になるが、それをやるだけの価値は十分にある。これは新しいことを始めるときのイニシャルコストだ。新しいクラスを作るとか、新しいメソッドを作ろうとしたときに、的確な命名をするというイニシャルコストをかけておけば、確実に可読性が向上する。結果、その後の設計フェーズでもコストダウンにつながるし、メンテナンスフェーズでもコストダウンにつながる。
自己投資でもある
実のところ、それ以上に効果があるのは、自己投資につながる点だと言える。こういう命名のような作業はある意味のトレーニングでもあるので、真剣に取り組んだ経験を重ねることはスキルアップにつながる。設計の質が向上することや英語を覚えることは、スキルアップそのものだ。
悪い例
命名が不適切なために、グダグダになっているものの代表が Util クラスだと言える。どのプロジェクトにも存在しそうな Util という名前のクラス。ユーティリティクラスの問題点については、以前も書いたことがある。
≫[Java][OO]ユーティリティクラスの憂鬱
これの最後の方にも書いてあるけど、単純に Util とか Utilities ではなくて、少なくとも HogeUtilities というクラス名にすべきだ。そうすると、そのユーティリティクラスの責務をある程度は絞れるので、安易に機能を追加されることを避けられる。
