Rails Good Parts, Bad Parts

Transcript

1. Rails Good Parts, Bad Parts @willnet

2. 自己紹介 » 前島真一 aka @willnet or @netwillnet » ginza.rb から来ました

   » メドピアさんで技術顧問しています » https://github.com/willnet » https://twitter.com/netwillnet » https://blog.willnet.in

3. 技術顧問として 主に負債を減らしたり、負債の増加を防ぐために頑 張っています !

4. 技術顧問について詳しく知りたい方は こちらをどうぞ » Rails Developers Meetup で喋った » https://speakerdeck.com/willnet/ji-shu-gu- wen-toiudong-kifang

   » ブログ書いた » https://blog.willnet.in/entry/ 2018/04/09/101808

5. 今日のテーマは技術的負 債 !

6. 負債へのアプローチは2 つ

7. できてしまった負債を減 らす⬇

8. 新規開発で負債を増やさ ない⬆ !

9. 今日は負債を増やさない 話をします

10. 負債の増加を防ぐにはど うしたらよいか

11. Railsのレールに乗る

12. レールに乗る、とは？ » みんなよく言ってるけどふわっとした概念 » レールについてきちんと説明している文章がない ように見える

13. Railsが提供しているべんりな機能を活 用する = レールに乗る ここではこういう定義とします

14. Railsのべんりな機能 » たくさんある » こういうメソッドないかな？と思って調べると大 抵定義済み

15. べんりな機能を知らずに スクラッチで実装して微 妙な感じになるケースが よくある !

16. べんりな機能の具体例 » あまり知られていない&&知ってると便利なもの » 複数のお手伝い先で何回も言ってるやつ

17. has_many

18. みんな知ってる

19. 定義することで使えるよ うになる機能がたくさん ある

20. has_manyで使えるようになるものたち collection collection<<(object, ...) collection.delete(object, ...) collection.destroy(object, ...) collection=(objects) collection_singular_ids

    collection_singular_ids=(ids) collection.clear

21. has_manyで使えるようになるものたち collection.empty? collection.size collection.find(...) collection.where(...) collection.exists?(...) collection.build(attributes = {}, ...)

    collection.create(attributes = {}) collection.create!(attributes = {}) collection.reload

22. 全種類知ってますか？

23. collection=(objects), collection_singular_ids=(ids) » 既存のcollectionをいい感じに置き換える » has_many through の場合は中間テーブルを置き 換える

24. 合わせ技でつかえるview helper » collection_check_boxes これらをスクラッチで書いてしまう人めっちゃ多い (当社比)

25. コード例 ビールの銘柄にタグ付けをするコードを考えてみま す

26. None

27. modelはこんな感じ class Beer < ApplicationRecord has_many :taggings has_many :tags, through:

    :taggings end

28. 素直に書くと <% Tag.all.each do |tag| %> <%= form.label tag.name do

    %> <%= check_box_tag 'beer[tag][id][]', tag.id, beer.tags.find { |t| tag.id == t.id } %> <%= tag.name %> <% end %> <% end %>

29. 素直に書くと def update @beer = Beer.find(params[:id]) @beer.attributes = beer_params original_taggings

    = @beer.taggings taggings_ids = params[:beer][:tag][:id] delete_taggings = original_taggings.reject { |bt| taggings_ids.include?(bt.tag_id.to_s) } delete_taggings.each(&:destroy) add_tags = taggings_ids.reject { |id| original_taggings.map(&:tag_id).include?(id.to_i) } add_tags.each do |tag_id| @beer.taggings.build(tag_id: tag_id) end if @beer.save redirect_to @beer, notice: 'Beer was successfully updated.' else render :edit end end private def beer_params params.require(:beer).permit(:name) end

30. 一瞬では読めないです ね… !

31. 既存のタグと入力値との 差分を見て、必要なもの だけinsert, deleteして いる

32. 読みづらいしバグも入り 込みやすそう

33. 便利メソッドたちを使うと <%= form.collection_check_boxes :tag_ids, Tag.all, :id, :name %>

34. 便利メソッドたちを使うと def update @beer = Beer.find(params[:id]) if @beer.update(beer_params) redirect_to @beer,

    notice: 'Beer was successfully updated.' else render :edit end end private def beer_params params.require(:beer).permit(:name, tag_ids: []) end

35. 普通に書ける beer.tag_ids = params[:beer][:tag_id] » has_many :tagsでtag_ids=メソッドが生えてい る » いい感じに差分を見て中間テーブルをinsert,

    deleteしてくれる

36. これ、初めて知った人 ✋

37. どうやってべんりな機能を知るのか » 公式のドキュメントやRailsガイドを読みましょ う » もしくは強い人にレビューやペアプロしてもらい ましょう

38. ここまでの話をまとめる と

39. Railsが提供するべんり な機能を使えば負債を作 らずに開発できる！

40. なんですけど…

41. Railsが提供している機能が全部無条件 に便利というわけではない » 安易に使うとやけどする機能もある » ググるといろいろでてくるはず » callback » default_scope

    » nested attributes

42. gemも似たように、安易に採用すべきで はないものがある » devise » simple_form » activeadmin » etc

43. この手のやつ、どう取り扱うべきか » チーム開発のときは特に慎重になったほうが良い » 禁止にしておいたほうが無難なことも多い » 利用シーンやチームの状況によって使えることも あるので、できれば吟味して決めたい

44. 例えばwebpacker » 最近よくdisられている » しかしフロントエンド専任がおらず、片手間でjs を書く&&とりあえずes6使いたい、というケース だと大変便利 » フロントエンド専任がいて、webpackの設定をち ゃんとしたい、というケースでは必要ない

45. 例えばdevise » 昔からよくdisられている » devise wayから外れるとつらい » 管理画面だけ認証が必要、などdevise wayで問題 ないならｻｯと導入できて便利

46. 要注意なものは » なぜ注意が必要なのか » どう避けるか » どういうときなら使ってもよいのか を把握してまとめておくと良い

47. 例えばhas_manyのcollection<<は要注 意 class User has_many :posts end これはイマイチな書き方 user.posts <<

    Post.new(title: 'hello world!')

48. なぜか collection<<は、レシーバのオブジェクトがDBに 保存済みか否かで挙動が異なる(クエリが発行され たり発行されなかったりする)

49. どう避けるか user.posts.build(title: 'hello world!') user.posts.create(title: 'hello world!') のように書いたほうが可読性が高く、事故りにくい

50. どういうときなら使ってもよいのか collection.build や collection.createが適切 でない、かつチームメンバー全員が挙動を理解して いればギリギリOKかと tag = Tag.create(name: 'Ϗʔϧ')

    Beer.each { |beer| beer.tags << tag }

51. (こうも書けるのであんまり例が良くな い) tag = Tag.create(name: 'Ϗʔϧ') Beer.each { |beer| beer.taggings.create!(tag:

    tag) }

52. このように » なぜ注意が必要なのか » どう避けるか » どういうときなら使ってもよいのか を把握してチーム内で共有したい

53. 負債を作らないために は、負債になりそうな要 素の対応法をみんなが理 解している必要がある

54. 少なくとも、レビューで 負債になりそうな要素を 止められるようにしてお きたい

55. 負債を作らないイコール 社内教育を頑張る

56. メドピアでは » 社内読書会 » ペアプロ » ふりかえり会 などしています

57. ところで、さっきの例は 簡単すぎ

58. 現実ではもっと判断に悩 むケースが多い

59. 判断に悩む例: コールバックをどう回 避するとよいか？ » フォームオブジェクト？ » サービスクラス？ » その他 ↑方針を決めたとして、具体的にどうやって作ると

    いいの？

60. なるべく具体的に「こう だ！」と道を示さない と、それぞれ思い思いの 実装になってそれが負債 につながる

61. しかし選択するのが難し い

62. そこで clean-rails.org ですよ

63. 可読性の高いRailsのコ ードを議論するコミュニ ティ

64. どのように実装するとよ いか判断に悩むときに相 談できる

65. 皆様からの投稿お待ちし ています !

66. まとめ » 負債を作らないためには、べんりな機能、要注意 な機能を知ることが大事 » 要注意なものについて、チーム全体で理解できる ように詳細を詰めて周知する » 勉強と教育をがんばりましょう

67. 判断に悩むものは一緒に 勉強していきましょう