この記事は虎の穴ラボ Advent Calendar 2024の7日目の記事です。

こんにちは、虎の穴ラボで Fantia の機能開発をしている awamo です。
今回は昨年ラムダノート株式会社より出版された「研鑽Rubyプログラミング」を紹介します。

本書を手に取った理由

少し前、言語仕様まで把握していると言える言語が欲しくて、Ruby技術者認定試験で Gold を取得しました。
ですが、実際に開発を進めていく中で、先輩が体得している実装の勘所というか、Rubyでより良いプログラムを創っていく上でのセンスのようなものが足りていない気がしていました。

そんな中で、こちらの書籍を発見したことが本書を手に取った理由です。
調べると Sequel Gemの作者でありRailsのコミッターであるJeremy氏が著した中級や上級を目指したい Ruby プログラマー向けの書籍とのことで、読み始めました。

書籍情報

項目	詳細
タイトル	研鑽Rubyプログラミング ― 実践的なコードのための原則とトレードオフ
著者	Jeremy Evans 著、角谷信太郎訳
原著	Polished Ruby Programming
ページ数	392ページ
発売日	2023/4/14
ISBN	978-4-908686-17-7

はじめに

実際に中級（だと信じている）の私が対象者向けの書籍を一読した感想をお伝えして、似たような方の参考になればと思います。

本書の大体の流れとしては、

PORO や Ruby を用いた一般的なプログラミングについての指針
Gemを作る上で製作者の視点としてどんなものがあるか
Webフレームワーク作者の視点でどう創っているか

が主なものとなっていました。

目の前のシステムを作るばかりで見えていなかった箇所も沢山あったので、私がこの書籍を読んでよかったと思えた箇所を、いくつかかいつまんでご紹介したいと思います。

本書で特に学びが多かったポイント

全体を通して、大先輩の頭の中を覗けたようでためになるところばかりだったのですが、私として覚えておきたいと感じた箇所は以下の通りです。

2.2.3 リスコフの置換原則
6.1 コードフォーマットにまつわる見解の違い
11.1 なぜそんなにもRubyではテストが重要なのか
14.3 存在しないコードよりも速いコードは存在しない

2.2.3 リスコフの置換原則

まず１つ目です。
原則そのものというよりも、原則の解説を通じて示されたものを紹介します。
章題のリスコフの置換原則それ自体については、この書籍や他の書籍に目を通していただきたいです。

紹介したいのは、この章で特に象徴的だった以下の1文です。

総じてRubyでは「プログラマーなら正しいやり方がわかるはず」という考え方を大切にしています

この1文に、私は何だか納得してしまったような覚えがあります。
動的型付けで、メタプログラミングによる動的なクラスやメソッドの定義ができるのも、DSLを簡単に作ることができるのもプログラマーを信じることを是とする言語であるからなのかな、という思いです。

代わりに、プログラマーが正しい判断を下せなければ容易に複雑なバグを生む原因にもなるのですが、そこは我々の頑張りどころなのかもしれません。
信頼に応えられるプログラマーでありたいですね。

６.1 コードフォーマットにまつわる見解の違い

ここで紹介されるプログラマーの類型としての「詩人」と「哲人」が、とても面白いものでした。

「詩人」は、コード上でさまざまな表現ができることを重視し、
「哲人」は、構文の一貫性や、意味の一貫性を重視する人を指します。

規模の大きなプロジェクトで開発を行う際には、これらの人にどう納得してもらうのかが生産性を考える上では大切そうです。

私個人としては、コードを書くときには読み下して何をしているのかが分かりやすくなっているかを重視しているので、同一の目的（データの作成や削除）を持つ操作であっても、その表現力の豊かさに乗じてさまざまなメソッド名をつけたくなってしまいます。
この点を見ると、私は「詩人」の性質が強そうです。

ただ、仕事で従事しているものはチーム開発である都合上、コードには規約があり、それに従う必要はどうしても出てきます。
最近では、規約に沿わせるためのコードの変更も行なっていますので、開発チーム全体としては「哲人」よりなのかもしれないですね。

現チームでは規約を整備しつつ、厳しいと感じたところは相談ができるので、納得の上で開発を進められています。

11.1 なぜそんなにもRubyではテストが重要なのか

テストは大切です。
大切なんですが、それがどうしてかということは案外頭の隅の方に追いやられてしまいがちです。

こちらの章では、どうしてRubyではテストが大切だと言われるのかを思い出させてくれます。

動的型であり、型エラーは動かさないとわからない
構文エラーも動かさなければわからない

など、基礎的なことではありますが、実装したものを動かしながら開発する大切さを思い出させてくれました。
上記の文だけ読むと恐ろしい話ですね。

Rubyでの開発は速くはありますが、型や構文の正しさは書いているだけでは担保できません。
なので、代わりにプログラマーがテストとして正しい動作を定義して、それを実行することが大切なのだと認識しています。
これも、プログラマーが正しいやり方をわかっていると信じているからこそ出来上がった文化なのかもしれないですね。

14.3 存在しないコードよりも速いコードは存在しない

はい。

私自身、何らかの機能を作る際に「どうやって作ろう」「この書き方の方が早くなるのでは」などと考えがちではあるのですが、そもそもコードを実行しないというのが何よりも早いという点は忘れがちだと思います。
CIを早くしたいと考えたときにも、結果的にいらなくなったコードを消すというのが一番効果的だったこともあります。
コードを置き換えるのではなく、不要になってしまったコードを残さないというのも、大事な考え方であることを共有したいと思います。

おわりに

こちらの書籍を読んで、思いがけず「プログラマーなら正しいやり方がわかるはず」というRubyという言語と、それを取り巻く環境の芯のようなものを知ることができた気がします。
Rubyという言語は表現力が豊かなので、プログラマー自身が責任を負う必要があり、だからこそ楽しく開発ができるのだと思います。

私はこちらの書籍を通して、大先輩の頭の中を少しだけでも覗けたような気がしています。
Rubyのことと、それを用いて開発をするときに覚えておくと嬉しいことが知れる、そんな書籍だったかと思います。
私が注目したのはプログラミングそのものというよりも、メタ的な部分が多くなってしまいました。
ですが、それ以外の技術的な話ももちろん盛りだくさんですので、興味が出るようでしたらぜひ目を通してみてほしいです。

以上、中級を自称する私から見て、印象的だった内容のご紹介でした。