What we learned from code review

Slide 1

Slide 1 text

永和のコードレビューから学んだ新人が語る Railsアプリケーションで押さえるべきポイント（株）永和システムマネジメント亀澤尚志 (@hisas) / 沼田周(@swamp09) Rails Developers Meetup 2018: Day 1 2018/03/24(土)

Slide 2

Slide 2 text

Slide 3

Slide 3 text

会社紹介

Slide 4

Slide 4 text

イベントへの参加補助

Slide 5

Slide 5 text

No content

Slide 6

Slide 6 text

https://www.wantedly.com/companies/esminc

Slide 7

Slide 7 text

Slide 8

Slide 8 text

自己紹介名前: 亀澤尚志 GitHub: hisas Rails歴 1年半名前: 沼田周 GitHub: swamp09 Rails歴 1年

Slide 9

Slide 9 text

Slide 10

Slide 10 text

諸注意 - 実際のプロジェクトであったレビューですが、一部改変しています。 - 解釈など間違っている部分があればご指摘ください。 - 永和の1プロジェクトのお話です。

Slide 11

Slide 11 text

No content

Slide 12

Slide 12 text

目次 - パフォーマンス改善 - リーダブルコード - メンテナンス - エラーハンドリング

Slide 13

Slide 13 text

パフォーマンス改善

Slide 14

Slide 14 text

N+1 - eager_loading を使ってクエリ回数を最小限にする - rails server のログをチェックする習慣を付ける

Slide 15

Slide 15 text

余計なインスタンス生成 - データ有無の確認は余計なインスタンスを生成しない exists? を使う

Slide 16

Slide 16 text

ループ中のDBアクセス - ループ中で何度もDBにアクセスするとかなり重くなる - Oracle の場合、SQLのIN句に入れられるのは一度に1000件

Slide 17

Slide 17 text

count, length, size の使い分け - count はSQLを発行して数え上げるのでレコード取得時は length, size を使う - count はレコード取得は不要で、件数のみの場合に使う

Slide 18

Slide 18 text

any? と empty? - AR の empty? はレコード取得前ではCOUNT方式のSQLを発行する - 気になったら Rails の中のコードを読んでみる

Slide 19

Slide 19 text

遅延評価 - lazy メソッドにより遅延評価して無駄な処理を避ける https://github.com/holiday-jp/holiday_jp-ruby

Slide 20

Slide 20 text

インデックス - データ量が多く、よく検索が行われる箇所はインデックスを貼るとよい - インデックスの書き込みに時間がかかるので注意

Slide 21

Slide 21 text

リーダブルコード

Slide 22

Slide 22 text

命名規則 - 省略した名前は読み手に負荷がかかるので絶対に使わない - 下手に抽象化するとメソッド名と中身が乖離してしまう

Slide 23

Slide 23 text

コーディング規約 - メンテナンスする上でスタイルが統一されていることは大切 - PRの本質ではない細かい所で指摘を受けないようにする

Slide 24

Slide 24 text

条件式 - unless で複数条件は読みにくく頭を使うので避ける

Slide 25

Slide 25 text

DRY - 二カ所以上で重複しているものを一つにまとめることで変更漏れを無くす

Slide 26

Slide 26 text

メンテナンス

Slide 27

Slide 27 text

データ変更処理をmigrationに書かない - マイグレーションでモデルを使用するのは危険

Slide 28

Slide 28 text

ロールバック - change だと、rollback できないものもある - up、downと使い分ける必要がある

Slide 29

Slide 29 text

OSS へのモンキーパッチ - モンキーパッチを当てるより、本家リポジトリにPRを送ってそのブランチを使用した方が良い - 将来マージされる可能性があり、メンテナンスしやすい - 特定の言語のライブラリに限らない

Slide 30

Slide 30 text

エラーハンドリング

Slide 31

Slide 31 text

updateとupdate! - update! は内部でsave!を呼び出している - update! は例外を投げるため。失敗時に気づける

Slide 32

Slide 32 text

コールバックがスキップされる - コールバックされないメソッドがある - されないことを理解した上で十分気をつけて使用する - updated_at が更新されないので、更新したい場合は自分で書く必要がある

Slide 33

Slide 33 text

良いエラーメッセージ - エラーメッセージは、あとで追跡調査をしやすいように

Slide 34

Slide 34 text

https://www.wantedly.com/companies/esminc