開発を担当した三年間の振り返り

Slide 1

Slide 1 text

開発を担当した三年間の振り返り @Takepepe / DeNA

Slide 2

Slide 2 text

吉井健文デザイン本部デザインエンジニアリングG DeSC / KenCoM 開発G

Slide 3

Slide 3 text

早いもので… DeNA入社して三年間経ちました。入社当初、フレームワークは React の View 部分が書ける程度。広告制作業界の Web屋、基本的に jQuery おじさんでした。

Slide 4

Slide 4 text

KenCoM というヘルスケアサービスを担当

Slide 5

Slide 5 text

KenCoM 歴もそろそろ三年この三年間で、サービス開発にたくさんコミットしました。新規機能追加・大規模改修などなど。悩み・考え、長期運用で得られたメモを、今日は共有したいと思います。

Slide 6

Slide 6 text

技術選定を振り返る

Slide 7

Slide 7 text

配属当初_φ(･_･担当事業は少しだけ Vue が入っていました。 Rails の assets pipeline で CoffeeScript をコンパイルするのを辞め、 Webpack と babel に乗り換えよう！というタイミングです。

Slide 8

Slide 8 text

React or Vue？_φ(･_･当時は Vue 使いも少なく、React 優勢の時代。最もエンジニアを確保できるフレームワークを選びたかった。社内的には Vue 案件の方が多かった当時、「React 案件を作り知見共有」という狙いもありました。

Slide 9

Slide 9 text

型システムをチームで保守可能か？_φ(･_･ React を導入した数ヶ月後、型システムを入れてみては？というタイミングが訪れました。チームで保守できたうえで、有意義なものになるのか、当初は懐疑的でした。負債になるのでは？という疑いとの戦いです。

Slide 10

Slide 10 text

型システム選択の失敗・成功_φ(･_･ React なら Flow でしょ、と踏んでいました。既存コードに上乗せ出来る事がありがたかった。型を早いうちに導入したこと自体は良かったです。いまではバリバリの TypeScript 厨です。

Slide 11

Slide 11 text

型システムの何が良かったか_φ(･_･作っているプロダクト要件が複雑で、常にリファクタを重ねる必要があります。型がなければ、ここまでやってこれなかったと思います。 VSCode に毎日助けられています。

Slide 12

Slide 12 text

やりたい！からの技術選定は良い_φ(･_･型システム導入時も結局「やってみよう」から始まりました。チームメンバーから「これをやりたい！」という意見が挙がったら、プロダクト貢献するか吟味したうえで、どんどん取り入れれば良いと思います。

Slide 13

Slide 13 text

技術選定で言い切れること_φ(･_･・流行りは追っかけた方がよい・流行りに流されない信念も必要・流行っているものは解決策が見つかり易い・npm trends 判断もだいたい正しい

Slide 14

Slide 14 text

設計を振り返る

Slide 15

Slide 15 text

状態管理で悩んだ_φ(･_･状態管理をどうするか、とても悩みました。モデルが必要だけど、Redux にはモデルがない。それでも、Redux はエコシステムが充実していて、設計を助けてくれることが分かっていました。モデル：）値を持ち、値の Read スタック・Write スタックを同期処理するもの

Slide 16

Slide 16 text

モデル駆動はうまくいった_φ(･_･ Redux にモデルを載せる手法を採用しました。 Mobx や Vuex の様なモデルの振る舞いが無ければ、複雑な UI は構築できなかったと思います。

Slide 17

Slide 17 text

Redux 過激派だった_φ(･_･ Redux による完全な Store 統治は過剰でした。 Stafull なコンポーネントを要所要所に起き、 UI の状態は UI で管理すべきでした。

Slide 18

Slide 18 text

いろんなライブラリを試してみると、「こことここ、同じ責務だ」という箇所が見えてきます。ライブラリは重ねて比較しましょう。ライブラリの共通点_φ(･_･

Slide 19

Slide 19 text

重ねて比べると、設計のマジョリティが見えてきます。他のライブラリで出来ない技がある場合、そこに知識を載せない工夫が必要です。設計のマジョリティ_φ(･_･

Slide 20

Slide 20 text

知識を切り出していくと、ライブラリに引きずられないテストの書きやすいコードが生まれます。そういうコードは何処でも動きます。知識の切り出し_φ(･_･

Slide 21

Slide 21 text

設計で言い切れること_φ(･_･・賢い UI は移植が大変・フレームワークに知識を載せない工夫が必要・設計の最適解はひとつではないが、共通項が多い・設計を常に変更できる線引きが重要

Slide 22

Slide 22 text

経年劣化対策を振り返る

Slide 23

Slide 23 text

経年劣化対策で悩んだこと_φ(･_･このフレームワークはいつ腐ってしまうのか？将来の自分・チームメンバーが「助かった」と思えるコードベースはどんな姿か？

Slide 24

Slide 24 text

経年劣化対策で学んだこと_φ(･_･経年劣化対策は、フレームワークに対してはほぼ無意味というのが現実でした。よく考えることは必要だけど、悩みすぎる必要はありませんでした。

Slide 25

Slide 25 text

経年劣化対策で成功したこと_φ(･_･ Redux Store に置いていた UI向けのモデルを、先日、React.Hooks にそのまま移植出来て大成功でした。知識の切り出しの成功事例です。

Slide 26

Slide 26 text

ライブラリには従う_φ(･_･知識を切り出しながら、ライブラリ作法には乗りましょう。切り出しはライブラリ劣化の備えです。やや面倒かもしれませんが、将来のコードの役に立ちます。

Slide 27

Slide 27 text

簡単な経年劣化チェック_φ(･_･ import をせずに処理が書き切れるものは、上流工程です。何かを import をしているファイル程、下流工程です。下流工程ほど、寿命が短いコードです。

Slide 28

Slide 28 text

純粋な言語仕様で完結する処理ほど、経年劣化に強いです。その事業専用の、0 dependencies なライブラリの様な姿になります。変化に強い上流工程_φ(･_･

Slide 29

Slide 29 text

その中で見えてくるのは、型定義が最上流工程ということです。全ての処理は型定義に依存しています。型定義は、プロジェクト知識の塊の様なものです。型定義が変化すると、号令の様に全てのコードが動きます。コードの最上流工程_φ(･_･

Slide 30

Slide 30 text

経年劣化対策で言い切れること_φ(･_･・フレームワークは、いつか必ず腐る・上流・下流の線引きが多いほど経年劣化に強くなる・線を引きすぎるオーバーエンジニアリングはNG ・頃合いをみて線を引き直す

Slide 31

Slide 31 text

三年間を振り返る

Slide 32

Slide 32 text

足りなかったこと_φ(･_･世間的にマイクロサービス化が進んでいる背景もあり、弊サービスもマイクロサービス推進中。フロントエンド弁慶でまかり通っていたので、 BFF と格闘しながらバックエンド力不足を痛感中。

Slide 33

Slide 33 text

良かったこと_φ(･_･任された課題に向き合うことができました。課題と向き合うことで、調べ・考え、知見が深まりました。長期運用で必要な配慮は、Web制作会社では得られないもの。入社時の希望していたキャリア感に近付きました。

Slide 34

Slide 34 text

意識的なアウトプット_φ(･_･解決した課題の、アウトプットを意識的に続けました。それが人との繋がりを生み、アンテナが伸びました。アウトプットを排出することで、アウトプットが連鎖しました。

Slide 35

Slide 35 text

課題への嗅覚があがった_φ(･_･アウトプットを続けることで、知らないことを知ることができます。新しい課題が見つかり、課題への嗅覚が上がります。アウトプットを続けることは、とても重要です。

Slide 36

Slide 36 text

ご静聴ありがとうございました