はじめに
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からは遠ざかってしまうのですが。）