イベント情報

https://icare.connpass.com/event/250699/

移り変わる技術や組織にどう対応するか

急激な伸びに対して、エンジニア組織が追いつかない瞬間。急な変化にどう対応するか。

作り直しの開発コスト

最初は Rails 3 / 4 から作り始めている
CoffeeScript がメインだった時代。
Vue をメインで使っているが、 CoffeeScript, jQuery も健在

強い気持ちを持って作り直す。
新規開発を止めて、作り直し、リファクタをする。

ビジネス側的には、新しい価値を届けることが大切。

開発コスト問題

• QCD(Quality / Cost / Delivery) のバランスが取れている
• 費用対効果が適切になっていること

が通っていると話は通る。

修正にかかるコスト < 修正で受けられるメリット, 開発コスト < 売上 を提示できると良い

10年を超えるプロダクトだと作るだけでなく、機能に対しての評価
他チームと共有できる指標に変換するのが大事

大事なこと：リファクタのタスクを落とさない

Rails が壊しやすすぎる

動かない < 動く <<<<< 綺麗な Rails

• StandardError
• Concernに分岐処理
• 大量のCallback
• Sidekiqの運用ルール
• ServiceClass
• etc...

言いたいこと

• DB / class 設計は、頑張っていることがある
• 細部が荒れて全体の品質が落ちることがある
• XXを作るときにYYを気を付ける

検知の大切さ

Railsはそもそも壊れやすい、時間経過でシステムや組織が大きくなると
意図せず不具合が出ることが多くなる。

パフォーマンス問題

• 数万レコードだと OK、数百マンレコードだと厳しいロジック
  • ex) scopeを呼びまくってしまったり
• 防ぐより検知する方が効率が良い

自動テスト

• CI
  • Rspec/FeatureSpec
  • Ject
• E2E
  • mabl
• Deploy後の正常確認

タスクを落とさないために

担当者・期限・評価指標（ゴール）を明確化させることが大切