こんにちは、入社一年目のSです。
冷気が一段と深まり冬の訪れを感じる季節の中皆さんいかがお過ごしでしょうか。
今回は、Salesforceを触っている中で地味に私を苦しめたAPIの命名規則についてお話ししたいと思います。

システム開発やAPI連携において、命名規則は非常に重要な要素ですが、意外と見落とされがちです。特に開発チームなど複数で作業している場合、一貫性がない命名規則は後々大きな問題を引き起こします。今回は、命名ルール作成の重要さと命名規則を守らない場合の問題点と、良いAPI名の例を紹介したいと思います。

API命名規則ルールを作成しないとどうなるか

お仕事でSalesforceを触る際、Salesforceの環境で項目やフローを作成するのが複数人になることも多々あると思います。そんな中あるオブジェクトではPascalCase(頭文字と文字区切りの場合大文字),あるオブジェクトではCamelCase(小文字始まりの大文字区切り)など各々のルールで命名してしまうとどの項目がどのような意図で作られたものなのかがわからず、のちの確認作業で時間を取られてしまいます。
ですのでAPI名には作成したものを英訳したものが一般的になります。

API命名規則を守らないとどうなるか

私が体験したものだけでも以下の三つのことが起こりました。

・数式項目の確認が難しく、どんな項目を参照しているのかが一目ではわからない
・ドキュメントが整理されておらず、一貫性に欠けるため、各項目が何を表しているのかを把握するのが困難
・Gitにマージする際、項目が何であるかが不明確なため、作業の効率が下がる

他にも先輩から聞いた話なのですがAPEXでの呼び出しやデバックテストなどでAPIが些末なのもなっていると対応に時間を取られてしまうそうです。ですのであらかじめ命名規則を定義しておくことが大事になります。

良いAPI命名規則の例

良いAPI名は以下のような特徴を持っています。

・直感的で説明的なもの、名前を見ただけで何をするAPIなのかがわかる
・一貫性があるもの、同じリソースや操作には同じ命名規則を適用する

上記のほかにAPI名の英文を最初に説明したPascalCaseやCamelCaseのほかに文をアンダーバー(_)で区切るSnakeCaseなどがあります。これらは項目、フローなど作成したものによって使い分けを行うとより一層わかりやすくなります。

インターネット上に日本文を自動的にSnakeCaseやPascalCaseにしながら翻訳してくれるサイトなどもあるのでそちらを使用するとAPI名を決める時間がより短縮されます。

最後に

API命名規則を一貫して守ることは、API設計だけでなく、システム全体の開発においても非常に重要です。特に、複数のチームや開発者が関与する場合、共通のルールを定めておくことで、コードの統一感や整合性が保たれます。細かいかもしれませんが小さな事でもルールを作成しそれを遵守していくことで迷わず作業が行うことが可能になり、そして完成度の高いものが作られていくものだと私は思っております。