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
660
App Router への移行は「改善」となり得るのか?/ Can migration to App Router be an improvement
takefumiyoshii
8
2.7k
フロントエンドの書くべきだったテスト、書かなくてよかったテスト
takefumiyoshii
37
14k
Webフロントエンドのための実践「テスト」手法 CodeZine Night #1
takefumiyoshii
24
8.1k
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.5k
Type-only Migrate by AST
takefumiyoshii
1
600
Other Decks in Technology
See All in Technology
dxd2024-生成AIに振り回された3か月間の成功と失敗/dxd2024-link-and-motivation
lmi
2
260
VPoEの視点から見た、ヘンリーがサーバーサイドKotlinを使う理由 / Why Server-side Kotlin 2024
cho0o0
1
420
運用改善、不都合な真実 / 20240722-ssmjp-kaizen
opelab
17
8.4k
OSSコミットしてZennの課題を解決した話
dyoshikawa1993
0
150
技術負債による事業の失敗はなぜ起こるのか / Why do business failures due to technical debt occur?
i35_267
0
190
[2024最新版]AWS Control Towerを使ったセキュアなマルチアカウント環境の作り方
hiashisan
0
270
データベース研修 分析向けSQL入門【MIXI 24新卒技術研修】
mixi_engineers
PRO
0
110
エンジニア向け会社紹介資料
caddi_eng
14
230k
セキュリティ研修 Day1【MIXI 24新卒技術研修】
mixi_engineers
PRO
0
160
地理情報とAPIのトレンド
nagix
0
160
ゆめみのアクセシビリティの現在地と今後
ryokatsuse
3
290
ACRiルーム最新情報とAMD GPUサーバーのご紹介
anjn
0
160
Featured
See All Featured
Side Projects
sachag
451
42k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
228
16k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
224
21k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
78
15k
Gamification - CAS2011
davidbonilla
78
4.9k
Leading Effective Engineering Teams 2024
addyosmani
3
300
The Invisible Side of Design
smashingmag
294
50k
Building a Scalable Design System with Sketch
lauravandoore
458
32k
Designing with Data
zakiwarfel
96
5k
Producing Creativity
orderedlist
PRO
340
39k
The World Runs on Bad Software
bkeepers
PRO
63
11k
Principles of Awesome APIs and How to Build Them.
keavy
124
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制作会社では得られないもの。 入社時の希望していたキャリア感に近付きました。
意識的なアウトプット_φ(・_・ 解決した課題の、アウトプットを意識的に続けました。 それが人との繋がりを生み、アンテナが伸びました。 アウトプットを排出することで、アウトプットが連鎖しました。
課題への嗅覚があがった_φ(・_・ アウトプットを続けることで、 知らないことを知ることができます。 新しい課題が見つかり、課題への嗅覚が上がります。 アウトプットを続けることは、とても重要です。
ご静聴ありがとうございました