リーダブルな命名はどこからやってくるのか

はじめに

弊社では週に2回エンジニアがほぼ全員集まって勉強会を開いており、その中で『リーダブルコード』を改めて読み直そうという輪読会が開かれました。

エンジニアであれば一度は耳にしたことであろうこの本では、アーキテクチャやデザインパターンといったコードの設計面ではなく、例えば変数名やコメントアウトといった、プログラミングの基本的なお作法と呼ばれるようなもののアプローチから、「理解しやすいコード」「読みやすいコード」「優れたコード」とはどういったものなのかを考察しています。

設計等のややこしい議論をカットして、基本的なテクニックの紹介に振り切るという潔さこそが、この本の名著たる所以でもあると思う一方で、そうした基本的なことを考えるには、 それを土台として支えるアーキテクチャが必要であり、それがあってはじめて成立する とも自分たちは考えています。
なので今回は、輪読会の中で議論されたことをまとめつつ、あえてマクロな視点を考慮したリーダブルな命名について考えてみようと思います。
（本記事はリーダブルコードの要約ではございませんので、本書の内容を知りたい方はぜひ読んでみてください）

結論

• 目的を明確に把握できる命名は理解しやすい。
• 適切に設計されたコードが、理解しやすい命名を生み出す。

目的が明確に把握できる命名

バックエンドで何かしらのUseCaseのクラスを作成する場合、私たちのプロジェクトでは基本的に動詞+目的語を含めるというルールで命名を行っています。
例えば、システムにユーザーを招待する機能があった場合は以下のようなコードになります。

// InviteUserUseCase.php

class InviteUserUseCase // 動詞: Invite, 目的語: User
{
    public function __construct(
      UserInvitationRepository $userInvitationRepository,
    ) {
    }

    public function handle(User $inviter, Email $inviteeEmail)
    {
        // ユーザーを招待する処理
    }
}

なぜこのようにしているのかというと、UseCaseとは端的に言えばアプリケーションの1つの機能であり、変更する頻度が高くなりやすいので、

• 解決する対象は何か
• なにをしてその問題を解決するか

を明確にし、そのUseCaseが 何を目的としたクラスなのかを命名から1発で把握できるようにしておく ためです。

共通の特徴があるグループに属するクラスは命名しやすい

UseCaseのように、何かしらのグループや層があるということは、その層の中に何か共通の役割や特徴を持ったクラスがそこに集められています。
なので、その共通部分に着目すれば命名に規則性やルールを持たせやすくなります。
例えば先ほどの動詞+目的語というルールも、UseCaseの特徴から生まれたものになります。

定めたルールに乗っかれば、命名の品質を一定保証することができ、またルールがレビューの基準にもなりますので、主観的なコードの良し悪しの判断を減らすことができます。

命名についてアレコレと頭を悩ませるのではなく、ルールを設けて不要な思考を制限する ことで、レビュアー・レビュイー双方が効率的に作業を進めることができます（もちろん、ルールでがちがちに固めすぎるのも考えものですが……）。

命名が難しい場面

しかし、常に命名が順調にいくわけではありません。

例えば1つのクラスから複数の振る舞いを外側に公開するようなクラスの命名は比較的難しいと言えます。
それらの振る舞いが矛盾なく自然に説明できるような命名をつけるのは、正直なところ、実装者のセンスに依る部分が大きくなると感じます。

こうした、良い命名を付けにくい場面に遭遇した場合はどうすれば良いのでしょうか？

優れた設計が良い命名を生み出す

こうした場合は発想を変えます。
つまり、良い命名を考えるのではなく、 良い命名が思いつかないコードの設計を見直す というアプローチを取ります。

例えば、先のようなクラスに対しては、そもそも複数の振る舞いを持つようなクラスが適切なのかと、根本のクラス設計から疑います。
究極的に言えば、本当にそのクラスは単一責務が守られているのかを疑う、ということです。

おおよそ命名が苦しいときは、そのコードの目的が何かを明確に定義付けできないときです。

• そのクラスによってどんな問題が解決されるのか？
• 何が実現されるのか？

そうした目的ベースでクラスを設計していくことで、自然と命名しやすいコードになっていくと考えます。

理解しやすい命名を考えるのではなく、各コードの目的を明確にできる優れた設計から理解しやすい命名が生まれてくる のです。