Ruby/Rails開発する際に知っておきたい省略用語集 2022年末版

morimorihogeです。

Railsを3.0betaの頃から触り始めてかれこれ12～13年くらい経ちました。これだけ長い間特定のライブラリやフレームワークを使い続けたことはなかったので、今やRuby/Railsには実家のような親しみを感じています。
今でも最盛期ほどではないとはいえRailsやRubyの利用は進んでおり、開発・周辺コミュニティも活発なため、日々新しくRubyやRailsに触れる人が増えています。自分の推しが新しい人達にも理解されるのはありがたいことです。うれしい。

一方で、長くRuby/Railsを使い続けているが故に昔からの利用者の中では当たり前のように使われている用語が新規参入者にとって「何この用語？」となってしまい疎外感を覚えてしまうということもあるのではないかなと思っています。
長くて濃いコミュニティができるほど「昔からの古参は知ってる」「これくらい知ってて当たり前」みたいな雰囲気が意図的ではなくても醸成されていくことで、なんとなく内輪感を感じて話に混じりにくく感じてしまう人もいるのではないでしょうか。
＃ フォローしておくと、Ruby/Railsコミュニティは開発者系コミュニティの中でも極めてオープンな志で運営されているものがほとんどのため、そのように感じるケースのほとんどは誤解だと思います（が、輪の外から見ると必ずしも理解されないこともまた事実です。むずかしい）

そこで本記事では、Ruby/Rails界隈で開発をしていると目に触れることのある省略用語（アルファベット数文字とかで記載されるもの）について思いついたものをまとめていこうと思います。

単純な専門用語であればググればいくらでも解説を見つけられるのですが、省略用語についてはググラビリティの低さから元から知らないと推測・調査のしようがないというケースにハマることがありますので、本記事はそういったケースで参照してもらえるようになれば幸いです。

各用語、具体的にどんなケースで使われるのかもなるべく例示していくようにしていますが、自分でこうした省略用語を使う際には相手がちゃんとその略語が伝わる人かどうかを確認して使うと良いでしょう。
ちなみに僕はコードレビューなんかでは省略用語をなるべく使わない様にしたり、初出時に省略してない用語を注釈するように気をつけています。

なお、省略しないバージョンの用語については公式ドキュメントにもRuby用語集というのがありますし、そうでなくてもRuby/Railsは品質の高いドキュメントがかなり世間に多い（日本語情報も多い）ので、各用語について詳しく知りたい人はさらにググってみると良いでしょう。

適宜追加・更新していこうと思います。

🔗 Ruby用語編

Ruby界隈の文脈でよく使われる用語です。Rubyに限らない用語もありますが、特にRuby界隈で良く見るものをピックアップしています。

🔗 PORO: Plain Old Ruby Object

外部Gemなどを使わない素のRubyの機能のみを使って作られるオブジェクトのことをあえて指してPOROと呼ぶことがあります。
RubyはRubyGems＋Bundlerという極めて利便性の高い外部ライブラリ利用環境があるので、特に初心者のうちはなんでもかんでも作る機能を誰かの作ったGemに頼るという考えに陥りがちです。
そういった際に「いや、それはわざわざGemを使うまでもなくそれRubyの標準機能の範囲でできるよ」みたいな文脈でPOROという用語がコードレビューなどの際に使われることがあります。

POROの具体例としてはStructやHash、あるいは素のRuby Classを用いる実装など比較的バリエーションがありますが、どれも追加Gemなどを必要としない「素の（Plain）」Ruby機能のみで実現することを指します。

🔗 MRI: Matz Ruby Implementation || Matz Ruby Interpreter （類：CRuby）

別名CRubyとも呼ばれます。狭義の意味でのRubyは言語仕様までのことを指し、処理系（具体的な実装）には複数の選択肢があります。
JRuby、TruffleRubyなど比較的名前を聞くものの他にも色々Ruby AssociationのRuby処理系の概要にまとめられています。

そうした中でMRI（CRuby）はRuby公式の処理系実装であり、多くのCPU/OSプラットフォームで動作し、新機能の議論などにも使われる最も一般的な処理系です。特に前情報なしにRuby利用の話がされるならまずMRIの事を指していると言って良いでしょう。
MRIという用語としては、処理系による違いを考慮しないといけないような文脈で使われます。

🔗 REPL: Read-Eval-Print Loop

これはRubyだけの特徴というわけでもないのですが、最近のスクリプト言語に搭載されることの増えたインタラクティブスクリプト実行環境のことです。RubyではIRB（Interective Ruby）が標準で搭載されている他、Pryにも根強い人気があります。

UNIXシェルと同じように、対話型コンソールを通じてRubyコードを1行ずつ実行することができます。これにより、ちょっとした処理であればRubyスクリプトファイルを使わずに実行結果を確認しながら動かすことができます。

🔗 DSL: Domain-Specific Language

ドメイン固有言語とかドメイン特化言語と訳される奴です。
RailsであればActive Recordの has_many や belongs_to、routes.rb に記述する resources ルーティングなどのRuby文法の中に埋め込まれるようなものが代表的なDSLとして挙げられますが、DSL自体は中間言語として利用されるようなものもあり、かなり広い範囲で使われる概念です。GemfileもDSLですしね。

Rubyはその仕様から新しい言語を作るのにとても向いていますので、一度くらいはオレオレ言語を作ってみると楽しいかと思います。特に、普段あまり自分でblockやyield、method_missingを使ったコードを書かない人は色々と発見があるでしょう。

🔗 AST: Abstract Syntax Tree

そのまま訳すと抽象構文木で、他のほとんどのプログラミング言語にも同様の概念が存在するものですが、Ruby周りを追いかけていると比較的良く見る単語かと思います。
コンパイラやプログラミング言語自体の設計に興味のある人は聞いたことのある界隈かと思いますが、その辺りを勉強したことのない人にとっては？？？となる界隈でもあります。
人間の読み書きできるRubyソースコードをRubyVMに実行させる過程の中で字句解析を行い抽象構文木を作成する、といったイメージなのですが、きちんと説明するにはこの記事スペースは狭すぎますので、ぜひ興味があればRuby言語自体について勉強してみて下さい。

ASTの存在を意識できると実践的にどういったことができるかというと、RuboCopのCop（ルール）のようなRubyコード自体の構造を解析するようなコードが書けるようになります。

• 参考：koicの日記: RuboCopのASTの書き方の例

他にも、他人の書いたRubyコードでどこから実行されるのか一見よく分からないコードなどはParser gemなどにかけてみると実際にどの順序で結合しているのかを調べることができて有用だったりと、知っていると助けられる・応用範囲の広がることが多々あります。

🔗 Rails用語編

Rails界隈で使われる用語です。

🔗 AR: Active Record

🔗 AM: Active Model

🔗 AS: Active Support

🔗 AC: Action Controller

🔗 その他Active/Action *系の省略語

文脈が明らかであればActive XXX、Action XXX系は長いので省略されることがあります。AR（Active Record）は比較的目にすることが多い一方で、AMやAS、ACなどはそこまで一般的には目にしないと思います。
ただ、Rails本家のIssueやPRでのやりとりやカンファレンススライドなどでは目にすることがあるため知っておくとびっくりしないので良いでしょう。

なお、Action MailerやAction Mailboxも省略したらAMだし被るじゃん！Active Storageも！という声もあるかと思いますが、この辺は皆さん文脈で判断してどちらのことを指しているのか判断しているようです。少ない文字数で伝わることが大事なのでそこまで用語としての一意性は求めていないのかもしれません。

AR以外はいきなり使うと伝わらないこともあると思うので、どうしても使いたければ初出時には注釈を付けるなどするのが親切かと思います。

🔗 CoC: Convension over Configuration

「設定より規約」より意訳的には「規約は設定に勝る」などと訳され、Railsの初期からある設計思想の根源です。Railsを象徴する用語なので、Rails開発するならこの言葉は知っておきたいですね。
直近のRails Doctrine（@takahashimさんによる日本語訳）ではThe menu is omakaseの中で触れられています。
詳細についてはググれば解説が無数にあるのでそちらを見て頂きたいですが、他のWeb開発経験がある人が初めてRailsを触ったときに感じる強烈な違和感というか魔術感を感じる要因でもあるのがこのCoCです。僕自身ライブラリの内部処理をある程度把握しながら使いたい人間だったので、最初は戸惑いました。

私見ですが、Railsがこれだけ広まったのもCoCにより「素のRails」という概念が開発者間のコンセンサスとして共有されていることがとても大きいと思います。カスタマイズ必須なフレームワークは一見高機能で開発者に寄り添っているように見えますが、その実同じフレームワークを使っていても実装スタイルや採用ライブラリはバラバラになりがちで、プロジェクトの暗黙知が大きくなりがちです。

暗黙知が増えると開発メンバーの離脱や入れ替え時のキャッチアップが大変になり、うまく引継ぎできないと捨てるしかないといった寿命の長いアプリケーション開発現場あるあるに陥りやすくなります。

CoC原則は他のフレームワークなら設定必須になっているような内容にもお任せ推奨設定が用意されていることで、そのアプリケーションが強くこだわりのない部分はこれを使おう、というのが用意されており、プロジェクトを渡り歩いたときの摩擦を低減してくれているのではないかと思います。

🔗 その他Ruby/Rails界隈用語

技術系の用語ではないものをまとめました。

🔗 DHH: David Heinemeier Hansson

Railsの生みの親であり今もなお開発の舵取りを行っている開発者です。Twitterアカウントは@dhhなので、最新Railsの動向を知りたい人はフォローしておくとよいかもしれません。
プログラマでありながらカーレーサーでもあるという、多趣味な人が多いエンジニア界隈でも珍しい経歴の持ち主です。
＃ 英語版Wikipediaによると、今はOreca 07に乗っているようです。

Railsがリリースされて20年弱が経ちますが、今でもRailsが変化を止めずに進化し続けているのは多くのcommitterや企業の貢献も大きいですが、DHHが恐れず新しいものを採用していくという要素も大きいと思います。
直近だとHotwireの公式採用は既存の流行フロントエンド開発とは違った新しいもので、当初は否定的な意見も多かったですが直近だと実際に触ってみたら良かった、という意見も聞こえてくるようになってきました。
今後も賛否両論はありつつもRailsに大きな影響を与える立場であり続けるでしょう。

🔗 RWC: RubyWorld Conference

Rubyのパパであるまつもとゆきひろ氏（@yukihiro_matz）の出身地でもある島根県松江にて、毎年秋頃に開催されるカンファレンスです。2022年は11/10-11開催でした。
※よく間違われますが「Ruby World Conference」ではなく「RubyWorld Conference」です

RubyKaigiなどの100%開発者向けのものとは違ってビジネス系の人達も参加するのが特徴で、悪く言えばdeepな開発ネタを求めている人には物足りませんが、よく言えば裾野の広い会議でもあります。
例年開催時期が松葉ガニの解禁時期だったりすることもあり、それ以外にも松江の美味しいものを求めて全国からRubyistが集まります。
＃ 会期中にタクシーに乗ったり居酒屋のカウンターで飲んでいると、プログラミングについて全くしらない人からも「あ、Rubyの人？」と声をかけられるくらいに地元でも認知されているという話はあるある話の鉄板です

🔗 プログラミング一般編

Ruby/Railsに限定されないが、Webを含むプログラミング一般用語でもあり、Rails開発では目にすることの多い用語をまとめました。

🔗 DDD: Domain-Driven Design

いわゆるドメイン駆動設計で、昨今の複雑化する一方のビジネスアプリケーション開発で良く取り上げられる設計手法です。
詳細はここに正確に書ききれる自信がないのでググったり書籍を読んで欲しいですが、悲しいかな表層で使われるツールや部分的なアプローチだけを拾い読みして実践した結果爆死するケースも多く、失敗経験から逆恨みを買い誤解されることの多い設計手法でもあります。

ここからは私見になりますが、DDDはプログラミング始めたての初心者や、ビジネス側の業務を知らないプログラマが突然やろうといってやってもまずうまくいかないので、ちゃんとドメインエキスパートの役割ができる人を決めてフルコミットさせるのが第一歩だと思います。
＃ というかこのあたりちゃんとしたドキュメント読んでれば絶対書いてあるはずなんですが、この一歩目すらやってないDDD失敗例が多くて草も生えないですね💦

🔗 EoL: End of Lifecycle

ソフトウェアやサービスにおけるサポート終了時期を示す用語です。
EoLが意味する所はそのソフトウェアやサービスによっても異なりますが、基本的にはEoLを過ぎる前に新しいバージョンに更新・移行しなくてはいけないもの、という認識は持っておく必要があります。
Rails開発ではRuby（MRI）のRuby Maintenance Branchesページ、Rails GuidesのMaintenance Policyページ、その他使っているRDBMSやLinuxディストリビューションについては最低限見ておく必要があるでしょう。

ソフトウェアやライブラリのEoL監視は運用側のチームがやるべきという意見もあるかもしれませんが、ディストリビューションやパッケージマネージャで入るソフトウェアはともかくアプリケーションが使っているライブラリや実行環境のEoLはアプリケーション開発者が一次情報を得ることがほとんどなので、基本的には開発サイドから警告を上げるものなのではないかなと思います。

🔗 PoEAA / PofEAA: Patterns of Enterprise Application Architecture

ソフトウェアアーキテクチャの著名な本を多数執筆しているMartin Fowlerの著書のうち、Patterns of Enterprise Application Architectureのことを略して呼びます。
2012年出版なので流石に現代では古いのでは・・・と思いきや、概念レベルでは色あせないことが多くて今読んでも学べることがあります。

ただ、設計に関する本ということで内容の抽象度は高めのため、少なくともある程度ビジネスアプリケーション開発経験があること、可能なら2つ以上のアプリケーションフレームワークを使ったことがあると理解を深めやすいかなと思います。そして日本語訳は結構品質が厳しいので、訳の怪しさを疑ったときのために英語版も手元に欲しい・・・となると中古で揃えても結構な金額になってしまう辛さはあります。

なお、RailsのActive RecordはPoEAAのアクティブレコードパターンが元になっています（そのはず）が、書籍の方を読んでみるとRailsのActive Recordがアクティブレコードパターンそのものというわけではなく、Active Recordの設計にはその他のパターンも複数採用されており、その結果今の超高機能ORMができあがった、ということが推察できます。

🔗 TDD: Test-Driven Development

テスト駆動開発のこと。2000年代前半ごろはまだテストコードを書くことに工数を割くことに対して理解が得られづらかった記憶がありますが、現代だと歴史的・技術的理由がない限りはほとんどの環境で一般的になったのではないかと思います。

🔗 BDD: Behavior Driven Development

振る舞い駆動開発と呼ばれ、Rails界隈では一時期CucumberやTurnipというBDDテストライブラリがとても注目されていた時期があります。
簡単に説明するなら自然言語でシステムの機能のシナリオ（振る舞い）を記述すると、記述したシナリオがそのままテストコードとして動くという世界の話になります。

究極的には上流工程が記述した仕様がそのままテストコードとして動く、という世界を描いていて個人的にはとてもエキサイティングな試みだったと感じているのですが、いかんせん日本語との相性が悪かったというツール的な要因の他、顧客・上流サイドがきちんとしたシナリオを記述するということの難易度がとても高かったのが厳しかった記憶があります。

🔗 DRY: Don't Repeat Yourself

コードの重複を避けるように共通化しましょう的な標語です。よく言われるやつですが、初心者にも分かりやすくて実践しやすいが故にやり過ぎてどハマりしがちなやつです。

RailsはフレームワークとしてとてもDRY原則を意識して作られているのですが、WebアプリケーションのようなエンタープライズアプリケーションにどこまでDRY原則を適用すべきかは気をつけたい所です。

ソースコードだけで見ていると重複したコードに見えて共通化したくなるコードも、ドメインロジックの視点から見ると共通化すべきではなさそう、といった事もあるので局所最適化ややり過ぎには気をつけたい所です。

🔗 おまけ

🔗 REE: Ruby Enterprise Edition

これを知ってたら古参です。
その昔（Ruby 1.8.7の頃）Railsで使うRuby実装といったらこれでした。RailsサーバーにはPhusion PassengerとかMongrelが使われていましたね。
なお、公式HPによると2012にはEoLを迎えているので、流石にもう現代で動いているところはないと思います。

まとめ

そんなわけで思いつくままに書いてみました。解説を書いていたらやたら長くなってしまいましたが、まだ思いついたら更新していこうと思います。

---