$30 off During Our Annual Pro Sale. View Details »

リフォーム Rails app

リフォーム Rails app

Rails Developers Meetup 2018 Day 3 Extreme
https://techplay.jp/event/679666

More Decks by Hiroki HIROCASTER OHTSUKA

Other Decks in Technology

Transcript

  1. リフォーム Rails app
    hirocaster @ Railsdm 2018 Extreme

    View Slide

  2. About me
    hirocaster ( Hiroki Ohtsuka )
    株式会社ミクシィ XFLAG開発本部 たんぽぽG
    モンスターストライク/新規事業、etc
    https://hiroki.jp/profile
    JRuby, Elixir, Ruby, Padrino, PHP, Chef, Puppet, Agile, Scrum,
    XP, TDD, CI/CD, DevOps
    著書: GitHub実践入門 ~Pull Requestによる開発の変革 など

    View Slide

  3. 前提
    この話は老朽化したRailsアプリケーションを修復して快適に住ん
    でいくためのTips集です。
    こんな時に思い出してみてください
    既存のプロジェクトの後からjoinした時に
    技術的負債を積立ないための仕組み作りの時に
    Railsのメジャーバージョンアップや大規模な改修の前に今回紹介
    するようなことを済ましておくことをおすすめします。

    View Slide

  4. 範囲
    Rails/Rubyなど利用した方法を範囲とします
    Railsのメジャーバージョンアップ方法には触れません
    インフラ、チームマネジメント、人間寄りの開発手法には触
    れません

    View Slide

  5. さて、はじめましょう。

    View Slide

  6. 開発環境を整える
    テストを追加したり、簡単に動作を確認できるようにすれば、比
    較的安全にシ
    ステムに変更を加えることができる状況にする。
    Setup CI/CD
    Travis CI, Circle CI, GitLab, Jenkins
    Setup Testing Framework
    TestUnit, RSpec
    Setup Staging
    システムを破壊してもユーザ影響のない環境を
    気軽に動作確認できることが必要

    View Slide

  7. セキュリティ
    脆弱性のあるバージョンを利用するのをすぐにやめる
    Rails/Rubyのverup
    パッチバージョンを上げられないかリリースノートを確

    バージョン番号について Semantic Versioning
    GitHubからのセキュリティアラート
    About security alerts for vulnerable dependencies - User
    Documentation
    Gemfile.lock
    bundler-audit
    Breakman
    実際のコードを修正して脆弱性を修正/抑制する
    ヒューマンミスでも脆弱性を作りづらいコードを書く
    updateするだけの作業はさくっとやってしまおう

    View Slide

  8. フレームワーク/ライブラリ都合の変更作

    FactoryGirl -> FactoryBot
    depricate method
    depricate gem
    paperclipとか...
    置きかえるだけなら、サクっとやってしまおう

    View Slide

  9. 次からは頭をつかっていく

    View Slide

  10. おかしなコード
    新参者が見ると慣れがないので見つけやすかったりする
    おかしいかも? なコード
    歴史的に不要になったけど削除されてないコード
    warningが発生しているもの
    大幅な変更時に壊れたままのコードなど
    本来はこんなコードは無いことが望ましい

    View Slide

  11. 実際におかしなコードをあぶりだしてみ

    View Slide

  12. おかしなコードをあぶりだす(0)
    おかしなところは…?

    View Slide

  13. おかしなコードをあぶりだす(1)
    Syntax Checkerの力をかりると…
    ruby-lint, IDE(RubyMine) とか使う

    View Slide

  14. おかしなコードをあぶりだす(2)
    参考までに私の環境だと...
    emacs + flycheck(rubocop + ruby-lint)

    View Slide

  15. おかしなコードをあぶりだす(3)
    コードカバレッジを見てみると
    テスト無いようですねὠ

    View Slide

  16. 何がおかしいの?
    s
    o
    u
    r
    e
    c
    e
    [
    "
    l
    a
    s
    t
    -
    m
    o
    d
    i
    f
    i
    e
    d
    "
    ] ≠ s
    o
    u
    r
    c
    e
    [
    "
    l
    a
    s
    t
    -
    m
    o
    d
    i
    f
    i
    e
    d
    "
    ]
    おそらく変数名のtypo
    そもそも s
    o
    u
    r
    c
    e 変数が存在していない
    git logを確認してみる
    大きなメソッドを切り出したメソッドのようだ…
    元コード変数がそのままのこっているようだ…
    s
    o
    u
    r
    c
    e を引数として渡すのを忘れたようだ…
    その際にガード節も追加されてようだ…

    View Slide

  17. 正しい実装を把握する
    じゃあ、引数に s
    o
    u
    r
    c
    e を追加してtypo直せば良いの?
    コードの整合性を整えるのであれば、それだけでOK
    appとしては、それが正しい実装なのか?
    考え、確認する必要がある
    テストを書くと理解しやすい/しないと書けない
    理解できてないテストは考慮不足
    カバレッジを通すだけのテストなど

    View Slide

  18. で、どうしたの?
    処理を一通り確認するとガード節があることによって、if文まで来
    たときには必ずtrueになる。 => else の処理はいらない
    テストを追加する必要がなかった
    (到達できない処理なので追加できない)

    View Slide

  19. めざすのは
    ὡ コードの整合性が保たれている状態
    ὠ appとして期待されている動作をしている状態

    View Slide

  20. 他にあぶりだす方法は?
    実際に動作させてエラーを取得する
    ログファイルだけだと見にいく手間が面倒
    外部サービスを利用して、通知してもらうのがおすすめ
    Sentry, Rollbar, Airbreak
    エラーが発生する箇所は
    壊れている or 改善の余地がある

    View Slide

  21. 修正するときは?
    テストコードを追加/修正する
    保守性/互換性を考慮する
    どっちを取る?
    厳密な動作 or 保守性
    セキュリティを考慮
    簡単に脆弱性を埋めこまないコードの書き方
    1行変更するだけで脆弱性が発生するようなのは避け

    View Slide

  22. そもそも老朽化させないために...

    View Slide

  23. 負債を積立しない仕組みづくり
    CI, pre-commit などを利用して
    適切な時に
    適切なメッセージを
    誰もが理解できるように
    伝える "仕組み" をつくる
    今後、開発者が増えても開発がスケールしやすくなる
    参考: Scaling Teams using Tests for Productivity and
    Education

    View Slide