こんにちわyosiです。
ペパボに入社して初めてRailsに触れて、実務でRailsを書き始めて1年が過ぎました。そんな日々で自身がやってしまったバッドメソッドをまとめておこうと思います。
特に個人開発などしてる人はレビューなどもらう機会がないかもしれませんから、知らずにやっている項目もあるかもしれません。
本当は10個書こうとしてたのですが、思いつかなかったので6個です!
コントローラーに処理を詰め込みすぎない
Rails初心者のとき、とにかくControllerに処理を詰め込んでいました。
Controllerに処理をべた書きしていくと様々なデメリットがあります。コードの再利用性も悪くなります。
同じ処理がControllerの様々な箇所で記述され、メンテナンス性も落ちます。また、コードを網羅するテストを書こうとすることでRequestテスト(Controllerテスト)が無駄に大きくなってしまいます。
Controllerの処理は最小限にしましょう。
別の個所にまとめておくことで再利用性が高まります。
Modelに寄せられるロジックはscopeやmethodにしてModelに書きましょう。
これによってModel側にUnitテストを書けるのでControllerのテストコード量が減ります。
1つのControllerクラスで複数回使われる処理があれば、privateメソッドにまとめましょう。
複数のViewやControllerから利用される処理(is_login?メソッドなど)はHelperにまとめましょう。
複数のControllerで利用されている処理(その上、Viewからは使われそうにない処理)はConcernにまとめましょう。
テストを書く
超当たり前ですね。
しかし、恥ずかしながら僕はできてませんでした。
初心者のうちはコードを書くのでいっぱいいっぱいで、テストを書くのは重労働でした(初めて触れたRspec高機能すぎて何が書いてあるのかわからなかったというのもあります)。
テストコードを書いてくださいとレビューをいただいて、テスト書いたらコードがバグっていたという経験さえありました。。。
テストを書くことで書いた処理が正しく動いていることを確認できますし、テストを読むことでどんな処理が書かれているか知ることができるドキュメントにもなります。
また、誰かが処理を変更したときにテストが落ちれば意図しない処理が入ることを防げたり、Gemなどのアップデートもずっと気が楽になります。
僕はまだうまくないですが、TDD(テスト駆動開発)など効率的な開発手法が理想です。
大事なRakeタスクはlib以下に処理を書いてテストを書く
Rakeタスク自体にテストを書いてしまってもいいと思います。
テスト大事。
Rspecで1つのitの中にexpectは1つ
1つのitの中に複数のexpectを入れてるとき、最初のexpectが失敗するとそれ以降のexpectは実行されずテストの結果に表示されません。
これはわかりにくいし非効率なので1つのitの中にexpectは1つが原則です。
テストでprivateメソッドを覗かない
テストでprivateメソッドの結果が正しいか確認したいことはあると思います。
実際にこれをやるためには`instance.send(:method_name)`みたいなコードを買うことで実現できます。
しかし、本当は見えないものを無理やり見てるのに近いので、あまりいいことではないかもしれません。
privateメソッドの結果を見なければならない設計自体を見直すことも視野に入れましょう。
テストからセッションを覗いたり、変更している時点で設計的に良くない可能性が高い
Rspecでセッションを変更するためには
type: :request
で
allow_any_instance_of(ActionDispatch::Request).to receive(:session)\
.and_return({})
を使う書き方と
type: :controller
で
一度GETリクエストをした後(リクエストが一度も発行されていないとrequest.sessionが使えない)で
session\[:test] = 'hogehoge'
みたいに書く方法があります。
しかし、テストからセッションを覗いたり、変更している時点で設計的に良くない可能性が高いです。設計を見直したほうがいいかもしれません。