はじめに
こんにちは。2024 年 5 月からインターン生として開発に携わっている maczac150 です。
先輩方から受けるコードレビューの中で、命名についてのご指摘を頂くことがあります。自分はネーミングセンスが良くないからなあと思うときはありますが、磨けるものだそうです。
Ruby の生みの親である、まつもとゆきひろさん曰く、「名前は理解の試金石」だそうで、「適切に名前を付けることができる」と「その概念を理解している」は近いと述べています。逆の言い方をすれば、良い名前が付けられないのは、その概念をきちんと理解できていない可能性があるということですね。確かに思い当たる節はあります。
Techouse のインターンを始めるまでは、「自分が分かればいいや」くらいの気持ちで命名していましたが、そんな適当な考え方がまかり通るはずがありません。今回は普段の業務で得た、命名に関する教訓を書いてみたいと思います。
開発における命名の重要性
初めてプログラミング言語を学んだとき、命名の技術も同時並行で学んだ方はそう多くはないかと思います。プログラミング言語の教科書に載っているコード例は、ごく自明かのように名前が用意されており、どうやって命名したか知る由もありません。また教科書でしばしば「変数は箱」と説明されていることもあり、命名はあくまで「他の箱」と区別するためだけのラベル貼りでしかないという感覚が多少ありました。
単独で開発を進める場合、命名にこだわるメリットは一見多くはなさそうです。ただ自分で書いたコードであっても、時間が経てば書いた時の記憶は消え、他人が書いたコード同然となります。将来の自分の記憶を過信せず、変数やメソッドがどのような役割を果たすのか、一目見て理解できる命名を心掛けることは非常に有益です。
一方チーム開発であれば、他の人が読んだ時にすぐ理解できるような可読性の高いコードを書く意識は当然求められます。自分勝手なコードを書いてしまっては、どれだけ優秀な方であっても理解するまでの時間が長くなります。結果として、チーム全体の開発効率を下げることにも繋がりかねません。また仮に可読性の低いコードが本番環境にリリースされてしまえば、障害対応時の工数が増える可能性があります。
極端な例を挙げると、ユーザーの誕生日を格納する変数名がbirthdayではなくて、aだったら、どんな値が格納された変数なのか全く分かりません。Techouse の開発においても、他人が理解しやすいコードをリリースできるよう、チームの方々から丁寧なレビューを頂いています。
Rails の設計思想「CoC」
他人がすぐに理解できるコードをどう書くか、一から考えていく必要はありません。
Techouse では、Web アプリケーションフレームワークとして Ruby on Rails を使用しています。Rails では設計思想をいくつか打ち出しており、その 1 つに CoC(Convention over Configuration)があります。
CoC は「設定より規約が優先」という意味です。Rails では、Web アプリケーションの機能を実現する最善の方法が明確に示されており、Web アプリケーションの各種設定についても従来の経験や慣習を元に、それらのデフォルト値を定めています。規約は開発者同士の共通認識であり、可読性が向上します。また規約に準じて命名することで、Rails 側がファイルや処理を自動生成してくれる等の恩恵も受けることができ、開発効率が上がるというメリットもあります。
Ruby のコーディング規約との比較
Ruby の正式なコーディング規約は存在せず、比較的緩やかです。そのため開発者の裁量に任される部分が多いです。
例えば「Ruby Association」と呼ばれる団体が、参考となるコーディング規約を以下のサイトで紹介しています。
一方で Rails は明確な規約があり、ファイル構造や命名規則などが厳密に定められています。「最善の開発方法は 1 つである」という判断の下で、それに沿った開発を全面的に支援しています。そのため、Rails で想定されていない別の開発手法は行いにくくなります。
自分がコードレビューで受けた指摘
安易に get から始まるメソッド名をつけない
自分は「クラウドハウス採用」と呼ばれる、様々な企業の採用活動を効率化するプロダクトの開発に関わっています。
主要機能の 1 つに媒体連携があります。
これは各求人媒体から応募の情報を定期的に取り込み、応募者データの一元管理を実現する機能です。バックエンド処理で、応募者データ等の様々なデータを取得しています。
連携媒体から応募者データを取得するメソッド名を考えた際、自分が初めに思いついた単語はgetでした。しかしこのgetという単語、コードを読む人に対して何の情報も提供していません。getという単語から、そのメソッドがどのような処理を行うのか推測するのは困難なため、好ましい単語ではありません。
例えば、応募データを一意に特定できる「応募 ID」を外部の媒体から取得するメソッド名は、get_application_idsではなくfetch_application_idsが適切です。英語辞典を見ると、fetchは「取りに行く」といった意味があり、外部から応募 ID を取得してくるという処理が推測しやすい名前となっています。
# 悪いメソッド名 def get_application_ids # 良いメソッド名 def fetch_application_ids
他の例としては、3 ヶ月前の日付を変数three_months_agoに格納するメソッド名は、get_date_three_month_agoではなくcalculate_date_three_month_agoの方が、実際の処理内容を反映していてわかりやすいです。メソッド内の処理としては、現在の日付を取得してから 3 ヶ月引くという「計算」を行っています。
# 悪いメソッド名 def get_date_three_month_ago # 良いメソッド名 def calculate_date_three_month_ago
このタスクでは、明確な単語を選択して名前に情報を詰め込むこと、他の単語でより良い名前をつけられないか再考する大切さを学びました。命名については「リーダブルコード」という書籍の中で詳細に触れられています。
他の方からフィードバックを頂く機会がないと、命名の技術を際限なく磨いていくことは難しそうですが、ある一定の技術は自己学習でも身につきそうです。他人が理解しやすいコードを書く意識を高めることができました。
RuboCop を使ってソースコードのスタイルを統一
命名に関連して、コードの可読性を高める別の取り組みにも触れておきます。
Techouse の開発では RuboCop を導入しており、コーディング規約が正しく守られているかを自動的にチェックしています。RuboCop は Ruby コードの静的解析ツールで、コードの品質やスタイルを向上させるために広く使用されています。具体的には以下のような機能を提供します。
- Linting：コーディングミスやバグの検出、デフォルト設定では「Ruby Style Guide」のコーディング規約から逸脱した箇所を指摘する。
- Formatting：インデント、スペース、改行などを調整する。
- 自動修正：一部の警告については、自動で修正が可能。
RuboCop が提供する上記の機能によって、既存コードの事情を深く知らないインターン生であっても、開発メンバーとコードの一貫性を保つことができています。
余談：試しにクラウドハウス採用の ABC size を見てみた
コードの複雑性を評価する指標として ABC size というものが存在します。ただし「ABC size の増加」と「コードの可読性の低下」は必ずしも一致せず(逆も然り)、あくまで指標の 1 つに過ぎないという点に注意が必要です。
RuboCop におけるひとつのルール単位のことを Cop と呼びますが、ABC size が設定値を超えているかを判定する Cop としてMetrics/AbcSizeがあります。
クラウドハウス採用は、1 つの Rails アプリを中心として、一部機能をマイクロサービスとして分割しています。今回は中心機能を担う Rails アプリについて、ABC size の分布を調べてみました。
.rubocop.ymlのファイルで、ABC Size チェックの設定値は 20 となっています。
現時点(2024 年 11 月 18 日)でのソースコードについて、テストコードを除く 2909 個のメソッドを対象に ABC size を調ベてみました。分布は以下の図の通りで、設定値を超えたメソッドは全体の約 6.5%にあたる 189 個でした。分布を見ると、かなり大きな値をとるメソッドが一定数存在しているようです。
クラウドハウス採用の媒体連携機能によって取得される応募データには、さまざまな情報が含まれています。具体的には、応募者の「氏名」「電話番号」「住所」等の個人情報や、「事業所名」「募集職種」等の求人に関する情報などです。こうした応募データを扱うにあたって、例えば各データ項目ごとに代入操作が行われるなど、プロダクトの性質として ABC size が大きくなる傾向にあります。
最後に
Techouse のインターンを始めるまでは、チーム開発の実務経験がなく、他人にコードを見られる機会もそう多くはなかったため、自己本位なコードを書いてしまっていました。最近では他の人にすぐ理解してもらえるよう、コードの可読性を高める意識が徐々に芽生えてきたような気がします。命名も含め、とても丁寧にコードレビューして頂けるので、毎回新しい気づきを得られています。まだまだインターン歴は浅いですが、今後もチームの方々が理解しやすいコードを書けるように意識していきます。
参考
Techouse では、社会課題の解決に一緒に取り組むエンジニアを募集しております。 ご応募お待ちしております。
