Meetup#9での発表資料です。 リクルートライフスタイル　岩下 太

1. レガシーと向き合い技術スタックを
代謝する(ElasticBeanstalk/Vue.js)
Futoshi Iwashita / RLS Meetup#9
リクルートライフスタイルの
フロントエンドのいまとこれから

2. • 岩下 太 (jaxx2104)
• 2017年5⽉ 中途⼊社
• フロントエンドエンジニア

3. 😭

4. 今⽇話したいこと
• これまで1年間レガシーと向き合ってきた話
• 最近の取り組みについて2つの事例を紹介

6. jQueryです

7. でもイメージよりは
ずっと良いプロダクトです

8. 独⾃フレームワーク
• jQuery + lodash.template + morphdom
の組み合わせ
• MVVMモデルでDOM操作は基本しない

9. ビルドツールは grunt から gulp,
webpack へと移⾏
ビルド時間の短縮
（特に開発時のcssビルド 60s -> 1s未満に改善）

10. Unit Test, E2E Test
• ユニットテストは ava, sinon
半年でカバレッジ率は 40% -> 60% に
• E2Eテストは Nightmare でUI差分取得

11. モックやドキュメント
• モックが⼀通り揃っているので開発のウェイトタイ
ムは少ない
• コードドキュメントは100%（OSSにPRを出して無
理⽮理カバレッジを上げたというのは秘密）

12. Codecov, Sentry
• カバレッジ率のチェックはCodecov
=> 積極的にテストを書く環境作り
• エラー検知はSentry
=> エラーの即時対応
=> 障害原因となりやすい画⾯実装について議論できる

13. レガシーと向き合いながら
⽇々の業務の中で改善している💪

14. 新規の開発案件での取り組み

15. ひとつめ（フロントの取り組み）
• 新規に3機能（フォームの多い設定画⾯）
• API通信・iOS連携・バリデーション
• Vue.js の導⼊検討

16. 事前に認識合わせ

17. 利⽤したもの
• Vue.js + Vuex + vue-router
• Vue スタイルガイド
• Atomic Design
• Storybook
• Prettier + eslint-plugin-vue

18. prettier + eslint-plugin-
vue

19. 良かったこと
• 仕様を決めながら⼤変だったがなんとか完成
• 画⾯と機能を分離できたことやコードフォーマットを
強制したことによる技術的な取り組み
• ⽅針の事前共有したことによるコミュニケーションの
取り組み
• UIパーツの移⾏ができたので既存画⾯についても移⾏
するきっかけとなった

20. 反省点
• 事前共有の段階で状態管理について踏み込んだ議
論ができると良かった
• ディレクトリ構成やコンポーネントの粒度はVue
のスタイルガイドやAtomicDesignを参考にし
たがやっぱり⼈それぞれ
• VeeValidate でハマった（Qiita書いた）

21. ふたつめ（インフラの取り組み）
• 新規顧客向けのデモモード機能の提供
• JSONのモックAPIサーバーの構築

22. ElasticBeanstalk + Node.js

23. ElasticBeanstalk
• 負荷分散、オートスケーリング、モニタリングを
よしなにやってくれる
• 環境設定のカスタマイズはコードベースでアプリ
ケーションと⼀緒に管理できる

24. M
4
M
4
M
4
M
4
ExtELB
ExtELB
In
tELB
In
tELB
U
ser
U
ser
A
u
to
Sca
lin
g
A
u
to
Sca
lin
g
C
lo
u
d
Fro
n
t
C
lo
u
d
Fro
n
t
Sta
tic
File
Sta
tic
File
B
a
ck
u
p
B
a
ck
u
p
V
ersio
n
in
g
V
ersio
n
in
g
Ela
stic
B
ea
n
sta
lk
Ela
stic
B
ea
n
sta
lk
C
lo
u
d
W
a
tch
C
lo
u
d
W
a
tch
D
evelo
p
er
D
evelo
p
er
構成図

25. アプリケーション構成

26. Immutable deploy

27. Rolling deploy
#
ver1 ver2ver1
#
デプロイ時に同じ環境に新旧のサーバが混在する
インスタンスを使いまわす事になる

28. Immutable deploy
😇 😇# #
ver1 ver1 ver2 ver2ver1
デプロイ時に環境を分けて作成する
インスタンスは常に新しい状態を保つ

29. 良かったこと
• フロントエンドエンジニアでも運⽤しやすいイン
フラ環境が構築が出来た
• Immutable Deploy は Node.js でクラス
タリングした場合に相性が良さそう
• インフラとフロントの関わりが強くなったこと
で、サービス開発を最⼤化できた

30. 反省点
• 既存インフラにElasticBeanstalkを寄せて
いくのは少し⼿間だった
• チームに展開するため運⽤フローをもっと早い段
階で整備すべきだと思った

31. 1年間レガシーと向き合って

32. フロントエンドエンジニアが
レガシーと向き合う場⾯って多い
• サービス開発の実現可能性を下げてしまう
• 同じ機能でもiOS/FE間の⾮機能要件での差異が⼤きい
• 競合他社が提供している機能が技術要件によって阻害されている
• フロントエンドエンジニアとしての評価
• 社外から⾒たとき最低限の技術スタックを満たせていない

33. フロントエンドエンジニアとして
技術スタックを代謝するために
• アプリケーションにフォーカスし続ける
• 常にクライアントのエンゲージメント向上に貢献する
• いつか良いレガシーとなる為にレガシーと向き合う
• それ以外（デザイン、インフラ etc..）
• フロントエンドエンジニアはバケツリレー要員として発⽣し
ている職能だと思っているので積極的に関与していく
• ⾃動化・省⼒化するところが⾒せ所

34. 以上です
ありがとうございました！