Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
リフォーム Rails app
Search
Hiroki HIROCASTER OHTSUKA
July 14, 2018
Technology
0
1.5k
リフォーム Rails app
Rails Developers Meetup 2018 Day 3 Extreme
https://techplay.jp/event/679666
Hiroki HIROCASTER OHTSUKA
July 14, 2018
Tweet
Share
More Decks by Hiroki HIROCASTER OHTSUKA
See All by Hiroki HIROCASTER OHTSUKA
Surge - Amazon DynamoDB for Elixir
hirocaster
2
2.5k
GitHubKaigi Keynote
hirocaster
22
43k
GitHubでつくる、たのしい開発現場
hirocaster
11
13k
Jenkins and GitHub
hirocaster
8
6.8k
Agile Development Leadership
hirocaster
1
2.2k
あたりまえのアジャイル と その先の世界
hirocaster
2
4k
サムライ・エピソード
hirocaster
1
2.5k
Let's Pair Programming
hirocaster
1
1.4k
The GitHub
hirocaster
2
24k
Other Decks in Technology
See All in Technology
バクラクのドキュメント解析技術と実データにおける課題 / layerx-ccc-winter-2024
shimacos
2
1k
成果を出しながら成長する、アウトプット駆動のキャッチアップ術 / Output-driven catch-up techniques to grow while producing results
aiandrox
0
180
re:Invent 2024 Innovation Talks(NET201)で語られた大切なこと
shotashiratori
0
300
LINEヤフーのフロントエンド組織・体制の紹介【24年12月】
lycorp_recruit_jp
0
530
組織に自動テストを書く文化を根付かせる戦略(2024冬版) / Building Automated Test Culture 2024 Winter Edition
twada
PRO
12
3.4k
マルチプロダクト開発の現場でAWS Security Hubを1年以上運用して得た教訓
muziyoshiz
2
2.1k
Wvlet: A New Flow-Style Query Language For Functional Data Modeling and Interactive Data Analysis - Trino Summit 2024
xerial
1
110
Snykで始めるセキュリティ担当者とSREと開発者が楽になる脆弱性対応 / Getting started with Snyk Vulnerability Response
yamaguchitk333
2
180
watsonx.ai Dojo #5 ファインチューニングとInstructLAB
oniak3ibm
PRO
0
160
プロダクト開発を加速させるためのQA文化の築き方 / How to build QA culture to accelerate product development
mii3king
1
260
LINEスキマニにおけるフロントエンド開発
lycorptech_jp
PRO
0
330
re:Invent をおうちで楽しんでみた ~CloudWatch のオブザーバビリティ機能がスゴい!/ Enjoyed AWS re:Invent from Home and CloudWatch Observability Feature is Amazing!
yuj1osm
0
120
Featured
See All Featured
Dealing with People You Can't Stand - Big Design 2015
cassininazir
365
25k
Documentation Writing (for coders)
carmenintech
66
4.5k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
45
2.2k
Java REST API Framework Comparison - PWX 2021
mraible
PRO
28
8.3k
Rails Girls Zürich Keynote
gr2m
94
13k
Music & Morning Musume
bryan
46
6.2k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
8
1.2k
Designing for Performance
lara
604
68k
Practical Orchestrator
shlominoach
186
10k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
44
9.3k
Fantastic passwords and where to find them - at NoRuKo
philnash
50
2.9k
Mobile First: as difficult as doing things right
swwweet
222
9k
Transcript
リフォーム Rails app hirocaster @ Railsdm 2018 Extreme
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による開発の変革 など
前提 この話は老朽化したRailsアプリケーションを修復して快適に住ん でいくためのTips集です。 こんな時に思い出してみてください 既存のプロジェクトの後からjoinした時に 技術的負債を積立ないための仕組み作りの時に Railsのメジャーバージョンアップや大規模な改修の前に今回紹介 するようなことを済ましておくことをおすすめします。
範囲 Rails/Rubyなど利用した方法を範囲とします Railsのメジャーバージョンアップ方法には触れません インフラ、チームマネジメント、人間寄りの開発手法には触 れません
さて、はじめましょう。
開発環境を整える テストを追加したり、簡単に動作を確認できるようにすれば、比 較的安全にシ ステムに変更を加えることができる状況にする。 Setup CI/CD Travis CI, Circle CI,
GitLab, Jenkins Setup Testing Framework TestUnit, RSpec Setup Staging システムを破壊してもユーザ影響のない環境を 気軽に動作確認できることが必要
セキュリティ 脆弱性のあるバージョンを利用するのをすぐにやめる Rails/Rubyのverup パッチバージョンを上げられないかリリースノートを確 認 バージョン番号について Semantic Versioning GitHubからのセキュリティアラート About
security alerts for vulnerable dependencies - User Documentation Gemfile.lock bundler-audit Breakman 実際のコードを修正して脆弱性を修正/抑制する ヒューマンミスでも脆弱性を作りづらいコードを書く updateするだけの作業はさくっとやってしまおう
フレームワーク/ライブラリ都合の変更作 業 FactoryGirl -> FactoryBot depricate method depricate gem paperclipとか...
置きかえるだけなら、サクっとやってしまおう
次からは頭をつかっていく
おかしなコード 新参者が見ると慣れがないので見つけやすかったりする おかしいかも? なコード 歴史的に不要になったけど削除されてないコード warningが発生しているもの 大幅な変更時に壊れたままのコードなど 本来はこんなコードは無いことが望ましい
実際におかしなコードをあぶりだしてみ る
おかしなコードをあぶりだす(0) おかしなところは…?
おかしなコードをあぶりだす(1) Syntax Checkerの力をかりると… ruby-lint, IDE(RubyMine) とか使う
おかしなコードをあぶりだす(2) 参考までに私の環境だと... emacs + flycheck(rubocop + ruby-lint)
おかしなコードをあぶりだす(3) コードカバレッジを見てみると テスト無いようですねὠ
何がおかしいの? 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 を引数として渡すのを忘れたようだ… その際にガード節も追加されてようだ…
正しい実装を把握する じゃあ、引数に s o u r c e を追加してtypo直せば良いの? コードの整合性を整えるのであれば、それだけでOK
appとしては、それが正しい実装なのか? 考え、確認する必要がある テストを書くと理解しやすい/しないと書けない 理解できてないテストは考慮不足 カバレッジを通すだけのテストなど
で、どうしたの? 処理を一通り確認するとガード節があることによって、if文まで来 たときには必ずtrueになる。 => else の処理はいらない テストを追加する必要がなかった (到達できない処理なので追加できない)
めざすのは ὡ コードの整合性が保たれている状態 ὠ appとして期待されている動作をしている状態
他にあぶりだす方法は? 実際に動作させてエラーを取得する ログファイルだけだと見にいく手間が面倒 外部サービスを利用して、通知してもらうのがおすすめ Sentry, Rollbar, Airbreak エラーが発生する箇所は 壊れている or
改善の余地がある
修正するときは? テストコードを追加/修正する 保守性/互換性を考慮する どっちを取る? 厳密な動作 or 保守性 セキュリティを考慮 簡単に脆弱性を埋めこまないコードの書き方 1行変更するだけで脆弱性が発生するようなのは避け
る
そもそも老朽化させないために...
負債を積立しない仕組みづくり CI, pre-commit などを利用して 適切な時に 適切なメッセージを 誰もが理解できるように 伝える "仕組み" をつくる
今後、開発者が増えても開発がスケールしやすくなる 参考: Scaling Teams using Tests for Productivity and Education