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.4k
Let's Pair Programming
hirocaster
1
1.4k
The GitHub
hirocaster
2
24k
Other Decks in Technology
See All in Technology
Azure AI ことはじめ
tsubakimoto_s
0
130
OSSコミットしてZennの課題を解決した話
dyoshikawa1993
0
150
データ分析基盤を作ってみよう~設計編~
nrinetcom
PRO
1
110
[NIKKEI Tech Talk]Bias for Action!! 実践から学ぶための仕組とコミュニティ / Community for Practice and Learning
kanamasa
0
270
E2Eテスト自動化プラットフォームにおけるAIの活用
shift_evolve
0
190
VPoEの視点から見た、ヘンリーがサーバーサイドKotlinを使う理由 / Why Server-side Kotlin 2024
cho0o0
1
420
[NIKKEI Tech Talk] KDDI/KAG Scrum & Community for Engineering Training
curanosuke
2
220
運用改善、不都合な真実 / 20240722-ssmjp-kaizen
opelab
17
8.1k
ABEMAにおけるLLMを用いたコンテンツベース推薦システム導入と効果検証
cyberagentdevelopers
PRO
1
730
AWSサービスメニュー開発をしていてAWSを好きだ!と感じた瞬間
toru_kubota
0
130
エンジニアの生存戦略 〜クラウド潮流の経験から紐解く技術トレンドのメカニズムと乗りこなし方〜
shimy
9
1.9k
プレイドにおけるDatadog APMの活用方法
plaidtech
PRO
2
120
Featured
See All Featured
How to name files
jennybc
67
96k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
12
3.8k
Facilitating Awesome Meetings
lara
46
5.8k
How to train your dragon (web standard)
notwaldorf
79
5.5k
Robots, Beer and Maslow
schacon
PRO
157
8.1k
The Illustrated Children's Guide to Kubernetes
chrisshort
39
47k
Keith and Marios Guide to Fast Websites
keithpitt
408
22k
10 Git Anti Patterns You Should be Aware of
lemiorhan
652
58k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
26
1.8k
Navigating Team Friction
lara
181
13k
Building Better People: How to give real-time feedback that sticks.
wjessup
357
18k
What the flash - Photography Introduction
edds
65
11k
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