はじめに

SQLアンチパターンをRailsの文脈で読み解いていきます。
この記事では、Ⅳ部アプリケーション開発のアンチパターン（19~25章）を取り上げます。

リンク

本文

19. リーダブルパスワード（読み取り可能パスワード）

deviseとか使いますよね。
bcryptを使う手もあります。

class CreateUser < ActiveRecord::Migration[5.1]
  def change
    create_table :users do |t|
      t.string :password_digest, null: false
    end
  end
end

password_digestカラムを用意して、クラス定義にhas_secure_passwordを書けば、
viewのフォームでpasswordとpassword_confirmationが使えるようになります。

class User < ApplicationRecord
  has_secure_password
end

オレオレ実装はNG。平文は論外。

20. SQLインジェクション

基本的にはHashで書くか、placeholderを使う。

Model.where(value: params[:value])
Model.where('value > ?', params[:value])

ActiveRecordを使ったSQLインジェクションの例はhttps://rails-sqli.org/ で見られる。

21. シュードキー・ニートフリーク（擬似キー潔癖症）

レコードを削除してできたidの歯抜けが嫌で、詰めようとしてしまう行為。
気持ちはわかるが我慢。気にしない。

22. シー・ノー・エビル（臭いものに蓋）

エラーを無視しない。当たり前。

Railsでいうと、saveとsave!の使い分けだったり、バリデーションとかか？
範囲が広すぎるので、書ききれない。割愛。

23. ディプロマティック・イミュニティ（外交特権）

一部の企業では、DBAが存在して、DB, SQLはバージョン管理しないみたいなことがあるそう。
本書では、文書化・バージョン管理・テスティングが有効と書かれている。

文書化
本にはER図がデータベースドキュメントの中で最も重要と書かれていますが、rails-erdというgemを使うと自動生成できたりもします。
バージョン管理
app/dbにあるので、管理しない理由が見当たらない。
テスティング
RSpecやMinitest書いてください。

24. マジックビーンズ（魔法の豆）

アクティブレコードパターンがアンチパターンというのでどうしようもなさがある。

とはいえ、 ActiveRecordは単なるアクティブレコードパターンではありませんし、100%当てはまるかは疑問です。
例えば、「24.2.2　アクティブレコードはCRUD機能を公開してしまう」の例を挙げます。

# 擬似コード
bug.assign_user(account)
mail_to(account)

のようにバグの修正担当にある人に割り振るとき、一緒にメールを送信するというロジックを作っても、それを知らない別のプログラマが

bug.assign_user(account)
#　メールは送らない

みたいに書いてしまう危険性があるとあります。
ただ、Railsの場合、コールバックを使えばいいのではと思います。それでも、skip_callback等の抜け道はありますが、意図的にやらない限り上のような状況にはならないでしょう。

25. 砂の城

データサイズが一ヶ月で3倍になったとか、色々イレギュラーなケースに想定しておきましょうという話。
この章にコメントを書けるほどの経験がないので、わかりません。
何もわからない。

全体通しての感想

経験がなくてよくわからないという箇所がいくつもあって、色々と限界を感じた。
プログラマ歴&Rails歴1年では厳しかったのか。
もうちょっと経験を積んだら追記したいところ。
（とはいっても、来月からC/C++を書くようなので、しばらくRailsからは遠ざかってしまうのですが。）