リフォーム Rails app

Transcript

1. 1.

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

2. 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による開発の変革 など
3. 3.

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

4. 4.

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

5. 5.

   さて、はじめましょう。

6. 6.

   開発環境を整える テストを追加したり、簡単に動作を確認できるようにすれば、比 較的安全にシ ステムに変更を加えることができる状況にする。 Setup CI/CD Travis CI, Circle CI,

   GitLab, Jenkins Setup Testing Framework TestUnit, RSpec Setup Staging システムを破壊してもユーザ影響のない環境を 気軽に動作確認できることが必要
7. 7.

   セキュリティ 脆弱性のあるバージョンを利用するのをすぐにやめる Rails/Rubyのverup パッチバージョンを上げられないかリリースノートを確 認 バージョン番号について Semantic Versioning GitHubからのセキュリティアラート About

   security alerts for vulnerable dependencies - User Documentation Gemfile.lock bundler-audit Breakman 実際のコードを修正して脆弱性を修正/抑制する ヒューマンミスでも脆弱性を作りづらいコードを書く updateするだけの作業はさくっとやってしまおう
8. 8.

   フレームワーク/ライブラリ都合の変更作 業 FactoryGirl -> FactoryBot depricate method depricate gem paperclipとか...

   置きかえるだけなら、サクっとやってしまおう
9. 9.

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

10. 10.

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

11. 11.

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

12. 12.

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

13. 13.

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

14. 14.

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

15. 15.

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

16. 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 を引数として渡すのを忘れたようだ… その際にガード節も追加されてようだ…
17. 17.

    正しい実装を把握する じゃあ、引数に s o u r c e を追加してtypo直せば良いの? コードの整合性を整えるのであれば、それだけでOK

    appとしては、それが正しい実装なのか? 考え、確認する必要がある テストを書くと理解しやすい/しないと書けない 理解できてないテストは考慮不足 カバレッジを通すだけのテストなど
18. 18.

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

19. 19.

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

20. 20.

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

    改善の余地がある
21. 21.

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

    る
22. 22.

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

23. 23.

    負債を積立しない仕組みづくり CI, pre-commit などを利用して 適切な時に 適切なメッセージを 誰もが理解できるように 伝える "仕組み" をつくる

    今後、開発者が増えても開発がスケールしやすくなる 参考: Scaling Teams using Tests for Productivity and Education