メソッドの命名にオーソドックスな prefix ってあると思うんだけど、そこから外れてるときってそもそも設計から見直した方がいいんだろうなぁ。例えば、個人的に業務のコードの中に calculate って出てくるとなんかぞわぞわする...。
— kntmr (@knt_mr) 2018年10月22日
これの補足ですが、処理の内容を端的な名前で表現できないとき、必要以上に複雑さを抱えている可能性があると考えていいと思います。なので、calculate みたいなやや抽象的なメソッド名を業務ロジックの中に見つけると不安になります。あと、execute とか、バッチアプリケーションのエントリポイントとかであればいいんですが、個人的にはこれも業務ロジックの中には出てきて欲しくない名前です。
そして、だいたいそういう名前のメソッドは処理が長くて多くの責務を持っている傾向にある気がします。一般的によく使われる単語で端的に名前が付けられないときは一旦立ち止まって考え直した方がよさそうです。あと、createXxxYyyZzz みたいに目的語(？)が多いときとか。
これらは設計の見直しやリファクタリングのサインになるわけです。
その他
自分はあまり見かけることはないですが、参照系のメソッドには副作用があってはいけません。あと、処理に必要なデータが存在しない場合、デフォルト値を返すか、例外とします。安易に null を返してはいけません。
find 系のメソッドは検索を伴い、リストを返します。条件に一致するものがなければ空のリストを返します。Optional を返してもいいと思います。null を返してはいけません。
delete は完全な削除、remove はある集合から取り除く、別の領域に退避するようなイメージです。ここは意識的に使い分けたいところ。
現場からは以上です。
