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
1つのHowに固執しない 場面に応じた最適な選択とは?
Search
Sponsored
·
Your Podcast. Everywhere. Effortlessly.
Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
→
nobuoooo
July 12, 2024
40
0
Share
1つのHowに固執しない 場面に応じた最適な選択とは?
nobuoooo
July 12, 2024
More Decks by nobuoooo
See All by nobuoooo
「すごい会議」で 振り返りが "変えることを宣言する場"になった話
nobuoooo
0
130
エンジニアよ痛みを知れ
nobuoooo
0
460
新規学習のハードルを下げる方法とは?/ How to Make Learning Something New Easier?
nobuoooo
1
310
チームにとって最適なスキルアップ施策とは何か/what-is-the-best-skill-up-approach-for-team
nobuoooo
0
360
Featured
See All Featured
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
47
8.2k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
122
22k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
133
19k
How to train your dragon (web standard)
notwaldorf
97
6.7k
First, design no harm
axbom
PRO
2
1.2k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
55k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
17k
Mind Mapping
helmedeiros
PRO
1
230
How to Think Like a Performance Engineer
csswizardry
28
2.6k
Paper Plane (Part 1)
katiecoart
PRO
0
8.5k
Side Projects
sachag
455
43k
Imperfection Machines: The Place of Print at Facebook
scottboms
270
14k
Transcript
1つのHOWに固執しない 場面に応じた最適な選択 とは? 土橋展之 ourly株式会社
インターン時代からourlyに参画。 “組織改善”という、市場がまだ出来上がってい ない領域にチャレンジできるフェーズに魅力に 感じjoin。 現在はバックエンドエンジニアとして働き、 Ruby/Rails, AWSを業務中によく扱う。 #サウナ #シーシャ #サッカー観戦
#ドライブ 自己紹介 土橋展之(つちはしのぶゆき) @nobuo_tsuchi
None
None
None
新しいことに挑戦し、外部にアウトプットする量 を増やすために登壇を決めました。 人生初の登壇 内容自体に新規性は少ないが、誰でも直面する可 能性のあることをお話しします。 自分と同じ轍を踏む人を減らしたいという思いで す。 自分と同じ失敗をする人を減らしたい 今日の発表の中でいいなと思ったことは、そのま まにせず自分の行動まで落とし込みましょう。
ぜひ行動まで移してほしい はじめに
今回のしくじりポイント 1つの手段に固執し、その手段でいかにうまくやるかを考えてしまったこと 実装前に戦略と戦術の観点から最適解を考えよう
背景 複雑な仕様 大量のデータ APIのリクエストを受け付けるたびに作成→返却 CSVファイル
背景 初期実装が完了。 しかし大量のデータの場合、実行にかなりの時間(数十秒ほど)が かかることが確認された。 このままではユーザー体験が悪いのでパフォーマンス改善が必 須であることが実装後に判明。
結果、何とか改善はできた N+1問題の改善やメモリ負荷の軽減などのパフォーマンスチュー ニングを行い、機能として何とかリリースできる状態にはでき ました。 しかし、もっと複雑な仕様 or もっと大量のデータの場合には限 界があるかもしれません。
ゴール 振り返ってみて 今回の実装が本当に最適解だったのか? 非同期処理(API実行中ユーザーは他の操作が可能) バッチ処理(APIではファイル返却のみ) 差分更新(変更が入った箇所のみ更新する) 代替案 手段 “リクエスト→ファイル返却” という機能はどの手法でも実現できる
他の場面でも同じ
他の場面でも同じ
Why What How Why What Strategy Tactics 手段は分解できる
Strategy 戦略 (実現のための方向性や作戦) 非同期処理やバッチ処理 隠しルートを使いボスの背後に 回る テニスラケットを使う Tactics 戦術 (作戦実行のために必要とな
る動き) APIのパフォーマンスチューニ ング ボスに正面から立ち向かう バットの振り方を練習する
Strategy 戦略 (実現のための方向性や作戦) 非同期処理やバッチ処理 隠しルートを使いボスの背後に 回る テニスラケットを使う Tactics 戦術 (作戦実行のために必要とな
る動き) APIのパフォーマンスチューニ ング ボスに正面から立ち向かう バットの振り方を練習する 適切な手段選択をすることが大事
結論: 今回のしくじりポイント 1つの手段に固執し、その手段でいかにうまくやるかを考えてしまったこと 実装前に戦略と戦術の観点から最適解を考えよう
まとめ 1つの手段でうまくいかない場合の選 択肢も考えるべき。 1つの手段にこだわるのは危険 手段のどのレイヤーで考えるべきかを 明確にする。 手段を考える際には “戦略”と“戦術”に分解する
We are Hiring!
Thank Thank Thank you! you! you!