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
開発を担当した三年間の振り返り
Search
Takepepe
March 15, 2019
Technology
1
2.3k
開発を担当した三年間の振り返り
Frontend de KANPAI! #6-みんなのサービスづくり- 登壇資料
Takepepe
March 15, 2019
Tweet
Share
More Decks by Takepepe
See All by Takepepe
ServerAction で Progressive Enhancement はどこまで頑張れるか? / progressive-enhancement-with-server-action
takefumiyoshii
7
740
App Router への移行は「改善」となり得るのか?/ Can migration to App Router be an improvement
takefumiyoshii
8
2.9k
フロントエンドの書くべきだったテスト、書かなくてよかったテスト
takefumiyoshii
37
15k
Webフロントエンドのための実践「テスト」手法 CodeZine Night #1
takefumiyoshii
24
8.2k
Next.js でリアーキテクトした話 / story-of-re-architect-with-nextjs
takefumiyoshii
12
8.5k
より速い WEB を目指す Next.js / nextjs-make-the-web-faster
takefumiyoshii
54
19k
フロントエンドの複雑さに耐えるため実践したこと / readyfor-nextjs-first
takefumiyoshii
25
11k
Redux の利点を振り返る
takefumiyoshii
26
8.6k
Type-only Migrate by AST
takefumiyoshii
1
610
Other Decks in Technology
See All in Technology
強いチームを夢見て-PMからSREに転身して1年の振り返り / 20240906_bengo4_sre
bengo4com
2
820
Datadog を使ったプロダクトとクラウドの セキュリティモニタリング
mrtc0
0
600
Oracle Autonomous Database:サービス概要のご紹介
oracle4engineer
PRO
1
6.9k
HolidayJp.jl を作りました
mrkn
0
120
20240906_JAWS_Yamanashi_#1_leap_beyond_the_AWS_all_certifications
tsumita
1
220
Binary Authorizationと友達になろう / Let's be friends with Binary Authorization
iselegant
2
140
EitherT_with_Future
aoiroaoino
1
930
マーケットプレイス版Oracle WebCenter Content For OCI
oracle4engineer
PRO
2
170
Zero Data Loss Autonomous Recovery Service サービス概要
oracle4engineer
PRO
0
3.2k
Mocking in Rust Applications
taiki45
1
110
四国クラウドお遍路 2024 in 高知 エンディング
yukataoka
0
160
Javaにおける関数型プログラミンへの取り組み
skrb
7
290
Featured
See All Featured
The Invisible Side of Design
smashingmag
295
50k
Git: the NoSQL Database
bkeepers
PRO
425
64k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
225
22k
VelocityConf: Rendering Performance Case Studies
addyosmani
321
23k
StorybookのUI Testing Handbookを読んだ
zakiyama
25
5k
Thoughts on Productivity
jonyablonski
66
4.2k
Scaling GitHub
holman
458
140k
Producing Creativity
orderedlist
PRO
340
39k
The Illustrated Children's Guide to Kubernetes
chrisshort
46
48k
What the flash - Photography Introduction
edds
67
11k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
42
2k
Principles of Awesome APIs and How to Build Them.
keavy
125
16k
Transcript
開発を担当した三年間の振り返り @Takepepe / DeNA
吉井 健文 デザイン本部 デザインエンジニアリングG DeSC / KenCoM 開発G
早いもので… DeNA入社して三年間経ちました。 入社当初、フレームワークは React の View 部分が書ける程度。 広告制作業界の Web屋、基本的に jQuery
おじさんでした。
KenCoM というヘルスケアサービスを担当
KenCoM 歴もそろそろ三年 この三年間で、サービス開発にたくさんコミットしました。 新規機能追加・大規模改修などなど。 悩み・考え、長期運用で得られたメモを、 今日は共有したいと思います。
技術選定を振り返る
配属当初_φ(・_・ 担当事業は少しだけ Vue が入っていました。 Rails の assets pipeline で CoffeeScript
をコンパイルするのを辞め、 Webpack と babel に乗り換えよう!というタイミングです。
React or Vue?_φ(・_・ 当時は Vue 使いも少なく、React 優勢の時代。 最もエンジニアを確保できるフレームワークを選びたかった。 社内的には Vue
案件の方が多かった当時、 「React 案件を作り知見共有」という狙いもありました。
型システムをチームで保守可能か?_φ(・_・ React を導入した数ヶ月後、型システムを入れてみては? というタイミングが訪れました。チームで保守できたうえで、 有意義なものになるのか、当初は懐疑的でした。 負債になるのでは?という疑いとの戦いです。
型システム選択の失敗・成功_φ(・_・ React なら Flow でしょ、と踏んでいました。 既存コードに上乗せ出来る事がありがたかった。 型を早いうちに導入したこと自体は良かったです。 いまではバリバリの TypeScript 厨です。
型システムの何が良かったか_φ(・_・ 作っているプロダクト要件が複雑で、 常にリファクタを重ねる必要があります。 型がなければ、ここまでやってこれなかったと思います。 VSCode に毎日助けられています。
やりたい!からの技術選定は良い_φ(・_・ 型システム導入時も結局「やってみよう」から始まりました。 チームメンバーから「これをやりたい!」という意見が挙がったら、 プロダクト貢献するか吟味したうえで、 どんどん取り入れれば良いと思います。
技術選定で言い切れること_φ(・_・ ・流行りは追っかけた方がよい ・流行りに流されない信念も必要 ・流行っているものは解決策が見つかり易い ・npm trends 判断もだいたい正しい
設計を振り返る
状態管理で悩んだ_φ(・_・ 状態管理をどうするか、とても悩みました。 モデルが必要だけど、Redux にはモデルがない。 それでも、Redux はエコシステムが充実していて、 設計を助けてくれることが分かっていました。 モデル:)値を持ち、値の Read スタック・Write
スタックを同期処理するもの
モデル駆動はうまくいった_φ(・_・ Redux にモデルを載せる手法を採用しました。 Mobx や Vuex の様なモデルの振る舞いが無ければ、 複雑な UI は構築できなかったと思います。
Redux 過激派だった_φ(・_・ Redux による完全な Store 統治は過剰でした。 Stafull なコンポーネントを要所要所に起き、 UI の状態は
UI で管理すべきでした。
いろんなライブラリを試してみると、 「こことここ、同じ責務だ」という箇所が見えてきます。 ライブラリは重ねて比較しましょう。 ライブラリの共通点_φ(・_・
重ねて比べると、設計のマジョリティが見えてきます。 他のライブラリで出来ない技がある場合、 そこに知識を載せない工夫が必要です。 設計のマジョリティ_φ(・_・
知識を切り出していくと、ライブラリに引きずられない テストの書きやすいコードが生まれます。 そういうコードは何処でも動きます。 知識の切り出し_φ(・_・
設計で言い切れること_φ(・_・ ・賢い UI は移植が大変 ・フレームワークに知識を載せない工夫が必要 ・設計の最適解はひとつではないが、共通項が多い ・設計を常に変更できる線引きが重要
経年劣化対策を振り返る
経年劣化対策で悩んだこと_φ(・_・ このフレームワークはいつ腐ってしまうのか? 将来の自分・チームメンバーが「助かった」と思える コードベースはどんな姿か?
経年劣化対策で学んだこと_φ(・_・ 経年劣化対策は、フレームワークに対しては ほぼ無意味というのが現実でした。 よく考えることは必要だけど、 悩みすぎる必要はありませんでした。
経年劣化対策で成功したこと_φ(・_・ Redux Store に置いていた UI向けのモデルを、 先日、React.Hooks にそのまま移植出来て大成功でした。 知識の切り出しの成功事例です。
ライブラリには従う_φ(・_・ 知識を切り出しながら、ライブラリ作法には乗りましょう。 切り出しはライブラリ劣化の備えです。 やや面倒かもしれませんが、将来のコードの役に立ちます。
簡単な経年劣化チェック_φ(・_・ import をせずに処理が書き切れるものは、上流工程です。 何かを import をしているファイル程、下流工程です。 下流工程ほど、寿命が短いコードです。
純粋な言語仕様で完結する処理ほど、経年劣化に強いです。 その事業専用の、0 dependencies な ライブラリの様な姿になります。 変化に強い上流工程_φ(・_・
その中で見えてくるのは、型定義が最上流工程ということです。 全ての処理は型定義に依存しています。 型定義は、プロジェクト知識の塊の様なものです。 型定義が変化すると、号令の様に全てのコードが動きます。 コードの最上流工程_φ(・_・
経年劣化対策で言い切れること_φ(・_・ ・フレームワークは、いつか必ず腐る ・上流・下流の線引きが多いほど経年劣化に強くなる ・線を引きすぎるオーバーエンジニアリングはNG ・頃合いをみて線を引き直す
三年間を振り返る
足りなかったこと_φ(・_・ 世間的にマイクロサービス化が進んでいる背景もあり、 弊サービスもマイクロサービス推進中。 フロントエンド弁慶でまかり通っていたので、 BFF と格闘しながらバックエンド力不足を痛感中。
良かったこと_φ(・_・ 任された課題に向き合うことができました。 課題と向き合うことで、調べ・考え、知見が深まりました。 長期運用で必要な配慮は、Web制作会社では得られないもの。 入社時の希望していたキャリア感に近付きました。
意識的なアウトプット_φ(・_・ 解決した課題の、アウトプットを意識的に続けました。 それが人との繋がりを生み、アンテナが伸びました。 アウトプットを排出することで、アウトプットが連鎖しました。
課題への嗅覚があがった_φ(・_・ アウトプットを続けることで、 知らないことを知ることができます。 新しい課題が見つかり、課題への嗅覚が上がります。 アウトプットを続けることは、とても重要です。
ご静聴ありがとうございました