リフォーム Rails app

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

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