Edited at

SQLアンチパターンon Rails Ⅳ部(アプリケーション開発)


はじめに

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のフォームでpasswordpassword_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でいうと、savesave!の使い分けだったり、バリデーションとかか?

範囲が広すぎるので、書ききれない。割愛。


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

一部の企業では、DBAが存在して、DB, SQLはバージョン管理しないみたいなことがあるそう。

本書では、文書化・バージョン管理・テスティングが有効と書かれている。


  1. 文書化

    本にはER図がデータベースドキュメントの中で最も重要と書かれていますが、rails-erdというgemを使うと自動生成できたりもします。


  2. バージョン管理

    app/dbにあるので、管理しない理由が見当たらない。


  3. テスティング

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