どんな本?
SonicGarden 株式会社ソニックガーデンのプログラマさんたちが書いた本です。
以下冒頭の本書についてからの引用です。
本書は Ruby on Rails を使った Web アプリケーション開発においてより良い書き方を提案する 技術書です。 対象読者は Ruby on Rails を使って何となくアプリケーションを書けるようになったけど、まだ自分のコードに自信が持てないというような、これから中級者を目指そうとしている方達です。 この本では私たちが所属しているソニックガーデンが運営している中級者向けプログラミングコ ミュニティ「ソニックガーデンジム」で実際にあったコードレビューを元に、具体例を交えながらより良いコードを提案します。
以下は各章ごとの感想です。
1章 モデル
1.1 中間テーブルのモデルは関係性を表す命名をする
安直にuser_magazineとかにしがちだなとおもったらまさにそのままのclass名だった。身に覚えしかない。
1.2 一般ユーザーと管理者ユーザーでモデルを分けるべき?
adminカラム作ってtrue or false でもいいと思ったけど、確かにAdminが不要なカラムをもってしまうことが多くなってしまっていたなと。
1.4 デフォルト値の定義にはattributeメソッドを使おう
enumerize便利とおもってたけど、default値の値には注意しないといけないのか。設定してるとnilでもdefault値に上書きされちゃうのか。
1.6 データベースに制約を設定する
Not Null制約をつけて、default値をつける話は
# userのnameにnot null制約を設定しない場合 if user.name # nameがある時の処理 else # nameがない時の処理 end # userのnameにnot null制約を設定し、デフォルト値を空文字にする場合 if user.name.empty? # nameがない時の処理 else # nameがある時の処理 end
ってかけてシンプルかなと思ったけど、他のコードで user.name&.upcase
みたいに書かなきゃいけないの嫌だな。それを気をつけなきゃいけないのも。
2章 View
2.1 ビューに複雑なロジックを書かない
ここが一番刺さった。つい先日レビューもらったところだった。viewにロジック書かない!で理解が終わってて、全部モデルに書いてたけど、その先があったんや。モデルにはサービスの本質的なロジックだけ書く。Decoratorはviewに関連しすぎてる処理をラッピングしてメソッド定義する。ViewComponent(cells)ではビュートそれに関連するロジックをセットで管理する。もらったレビューずばり。
2.4 時間、日付のフォーマットにはI18n.lを使おう
i18nの話してる時、<%= l Time.now %>
みたいなコードみると l
を i
だと勘違いしちゃうのはあるあるだと思ってる。
3章 Controller
3.1 一覧を取得する際にはorderをつける
一覧を取得するときに順番をつけるっていうのは最近twitterで社内のルール?として決めてるっていうのみたけど、ツイートみつからぬ、、
3.2 安全にオブジェクトを取得する
2回クエリ走っちゃいそうって思ったけど、そもそもcurrent_userがメモ化されてるから関係ないか。全体でfindしないで、user has many posts
なら user.posts.find
とした方が安全なのか。たしかにそうかも。postならまだよさそうだけど、他の重要な情報を他のuserが取得しうることになるのか。でも権限管理してれば大丈夫では?とも思ったけど、危険性を少しでも下げることが大事だという認識。
3.3 管理者と一般ユーザーのnamespaceは分ける
namespace切って余計な制御減らすって考え方は色々応用できそう。管理しやすいからって理由でnamespace切ることはあったけど、制御減らすためとは考えてなかったかも。
4章 Test
4.1 describe/context/it でテスト対象を表現する
「正しく動作すること」って書いてるのは私です。
4.3 システムテストでは操作後の結果まで確認しよう
view specって全然使ってないけど、割と使うのかな?
4.8 Strong Parameter の設定漏れを検知する
action_on_unpermitted_parametersって設定しらなかったので使っていきたい。
4.10 sleep は使ったら負け?
expect(page)でcapybaraが数秒(デフォルトで2秒)待ってくれるのはしらなかった。
4.11 効率よくテストを書く
システムテストは動線を確認、ユニットテストはロジックの詳細を確認。
5章 その他
5.2 gem バージョンを固定しない
gemを固定してしまうとバージョンアップのインパクトが大きいのは確かに。
5.5 命名について
date型のカラムは 動詞の過去形on で datetime型は 動詞の過去形at, bool型で_flgはさける。というのも、trueが結局どいう状態かわからないため。
5.6 禁止リストよりも許可リストを優先的に使おう
たしかに許可リストにしておけば、追加忘れても機能を使えないだけで、意図しない利用を防げるというのはあるな。安全第一。
5.7 コメントには言い訳を書く
わかりやすくするためのコメントより、わかりやすい命名を目指した方がいいのはたしかにだなぁ。説明的なコードを書くと。コメントは言い訳を書くところっていう表現面白い。
終わりに
自分も心当たりのあるレビューがたくさん載っていました この本に書いてあったことを意識しながらより良いコードを書けるように精進していきたいと思います 🙌