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.4k
開発を担当した三年間の振り返り
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
940
App Router への移行は「改善」となり得るのか?/ Can migration to App Router be an improvement
takefumiyoshii
8
3.3k
フロントエンドの書くべきだったテスト、書かなくてよかったテスト
takefumiyoshii
39
15k
Webフロントエンドのための実践「テスト」手法 CodeZine Night #1
takefumiyoshii
24
8.6k
Next.js でリアーキテクトした話 / story-of-re-architect-with-nextjs
takefumiyoshii
12
8.7k
より速い WEB を目指す Next.js / nextjs-make-the-web-faster
takefumiyoshii
54
20k
フロントエンドの複雑さに耐えるため実践したこと / readyfor-nextjs-first
takefumiyoshii
25
11k
Redux の利点を振り返る
takefumiyoshii
26
8.7k
Type-only Migrate by AST
takefumiyoshii
1
660
Other Decks in Technology
See All in Technology
2024AWSで個人的にアツかったアップデート
nagisa53
1
110
ゼロからわかる!!AWSの構成図を書いてみようワークショップ 問題&解答解説 #デッカイギ #羽田デッカイギおつ
_mossann_t
0
1.5k
あなたの人生も変わるかも?AWS認定2つで始まったウソみたいな話
iwamot
3
860
When Windows Meets Kubernetes…
pichuang
0
300
完全自律型AIエージェントとAgentic Workflow〜ワークフロー構築という現実解
pharma_x_tech
0
350
商品レコメンドでのexplicit negative feedbackの活用
alpicola
2
370
生成AI × 旅行 LLMを活用した旅行プラン生成・チャットボット
kominet_ava
0
160
Alignment and Autonomy in Cybozu - 300人の開発組織でアラインメントと自律性を両立させるアジャイルな組織運営 / RSGT2025
ama_ch
1
2.4k
あなたの知らないクラフトビールの世界
miura55
0
130
【JAWS-UG大阪 reInvent reCap LT大会 サンバが始まったら強制終了】“1分”で初めてのソロ参戦reInventを数字で振り返りながら反省する
ttelltte
0
140
Reactフレームワークプロダクトを モバイルアプリにして、もっと便利に。 ユーザに価値を届けよう。/React Framework with Capacitor
rdlabo
0
130
月間60万ユーザーを抱える 個人開発サービス「Walica」の 技術スタック変遷
miyachin
1
140
Featured
See All Featured
The Art of Programming - Codeland 2020
erikaheidi
53
13k
How STYLIGHT went responsive
nonsquared
96
5.3k
Code Reviewing Like a Champion
maltzj
521
39k
Docker and Python
trallard
43
3.2k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
30
2.1k
We Have a Design System, Now What?
morganepeng
51
7.3k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
365
25k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
59k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
33
2.7k
Music & Morning Musume
bryan
46
6.3k
Agile that works and the tools we love
rasmusluckow
328
21k
The Pragmatic Product Professional
lauravandoore
32
6.4k
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制作会社では得られないもの。 入社時の希望していたキャリア感に近付きました。
意識的なアウトプット_φ(・_・ 解決した課題の、アウトプットを意識的に続けました。 それが人との繋がりを生み、アンテナが伸びました。 アウトプットを排出することで、アウトプットが連鎖しました。
課題への嗅覚があがった_φ(・_・ アウトプットを続けることで、 知らないことを知ることができます。 新しい課題が見つかり、課題への嗅覚が上がります。 アウトプットを続けることは、とても重要です。
ご静聴ありがとうございました