研鑽Rubyプログラミング

国内公式?の感想まとめ

ライブラリ作者の目線や頭の中をのぞけるのは貴重

2,3年目のエンジニアによっしゃ真似したろ！って特攻させないようブレーキがかかっている（主観）

自分で判断できるようになる、っていうメッセージが響いた

テストやリファクタリングについて、一般的ではあるけどRubyを題材に説明してくれる

4章

クラスにメソッドを追加するにあたってまず自問すべきことは「このメソッドの後 方互換性を保つことにコミットしたいだろうか? 少なくとも次のメジャーバージョ ンをリリースするまで、ひょっとしたらこの先もずっとメンテナンスするかもしれな いのに? 」です。もし答えがイエスなら、パブリックメソッドにしましょう。ノー なら、プライベートにしておくべきでしょう。

メソッド の可視性としてプロテクティッドを選ぶことが適切なケースは 1 つだけです。具体的 には、「ライブラリ内部でのみの利用で、かつメソッドの呼び出し元が同じクラスの 別メソッドであり、しかも send を使うオーバーヘッドを避けたい」という場合に限 ります。

5章

ほとんどの場合、「想定していないエラー」や「一般的でないエラー」に対しては例 外を発生させるべきです。戻り値を使って処理させるべきではありません。

6章

恣意的な制限に反対する理由は単純です。制限の範囲内でうまくやれる方法がある なら、すでにそうなっているはずだからです。恣意的な制限に賛成する理由も単純で す。プログラマーはあまりにも無知蒙昧だったり経験不足だったりするので、何が最 善なのかを判断できないからです。そこで恣意的な制限を課すことにより、プログラ マーに自分の書いたコードの再構築を強制させることで、起こりうる損害を低減でき ます。ここで問題です。仮にプログラマーがあまりにも無知蒙昧だったり経験不足 だったりして、制限の範囲内で物事を正しくできないのだとしたら、何を根拠に彼ら が才知を発揮してコードを小さなパーツへと分割できると思えるのでしょう?

RuboCop が「あなた自身よりもよくわかっている」と想定してデフォ ルトの恣意的な制限をそのままにするのはやめましょう。あなたのコードの API にど んな意味があるのかを判断するのはあなたです。RuboCop に文句を言われるからと いって、メソッドの行数を削減するためにリファクタリングしてはいけません。

12章

後者をおすすめ

まずはリファクタリングのみを終わらせ、新機能の開発をする

13章

Ruby本体やbuilt-inライブラリで使っているパターンもある

14章

どこもかしこも遅いときに試すこと

大量のオブジェクトをメモリに割り当てているコードはRubyを遅くする原因としてよくある

14章

このセクションで紹介している 4 つのフレームワークうち、